nkcmr / flic Goto Github PK

I have two processes: one with a Bridge and na anonymous Node, another one with an anonymous Node.

When I shutdown the process (Ctrl-C) with standalone Node, the process with the Bridge displays the following error:
{ [Error: read ECONNRESET] code: 'ECONNRESET', errno: 'ECONNRESET', syscall: 'read' }

Adding myBridge.on("error"... or myFirstNode.on("error"... in the first process, that error is not catched.

However, I have mySecondNode.on("error"... and when I shutdown the process with the Bridge, the error callback is triggered.

Any hint?

Maybe I have been missing something, but I cannot see any host configuration.

It seems I can scale vertically, but if my nodes are distributed to remote machines, I cannot see how to set the host.

It would be interesting to change Node API, for instance, as new Node( [name], [host], [port], [callback] ), where parameter host is the Bridge host.

Does it make sense?

It seems, before telling again, the previous tell needs to be terminated.
It seems it is mandatory only once tell per time.

0.js

"use strict";

var flic = require("flic");

var Bridge = flic.bridge;
var Node = flic.node;

/*eslint-disable no-new */
new Bridge();
/*eslint-enable no-new */

var node0 = new Node("node0", function (err) {
    if (err) {
        console.log("node0 online error");
    }

    console.log("node0 online!");
});

setTimeout(function () {
    console.log("Sending messages");
    node0.tell("node1:event", "flic_is_easy 1", function (err1, args1) {
        if (!err1) {
            console.log(args1);
            node0.tell("node2:event", "flic_is_easy 2", function (err2, args2) {
                if (!err2) {
                    console.log(args2);
                }
            });
        }
    });
    // node0.tell("node2:event", "flic_is_easy 2", function (err2, args2) {
    //     if (!err2) {
    //         console.log(args2);
    //     }
    // });
}, 5000);

2.js

"use strict";

var flic = require("flic");

var Node = flic.node;

var node1 = new Node("node1", function (err) {
    if (err) {
        console.log("node1 error");
    }

    console.log("node1 online!");
});

node1.on("event", function (args, done) {
    console.log(args); // -> "flic_is_easy 1"
    done(null, "done 1");
});

var node2 = new Node("node2", function (err) {
    if (err) {
        console.log("node2 error");
    }

    console.log("node2 online!");
});

node2.on("event", function (args, done) {
    console.log(args); // -> "flic_is_easy 2"
    done(null, "done 2");
});

Output first console

$ node 0.js       
node0 online!     
Sending messages  
done 1            
done 2            

Output second console

$ node 2.js
node2 online!
node1 online!
flic_is_easy 1
flic_is_easy 2

If the tells are not nested (as the code commented out), you see only Sending messages with no any other message (no done and flic_is_easy).

This can happen it two processes create a bridge at the same time. The second one will fail silently, and really shouldn't.

In the case where I have a bunch of processes and 1 master, the first to create the bridge could declare itself the master. For that case, I need to be able to tell when it fails.

currently, when creating a new bridge, constructing a bridge will automatically start listening on the default (or provided) port.

it would be better if control was given to the API over .listen, as such:

var b = new Bridge()
b.listen(8221, function () {
  debug('im listening!!')
})

it would be nice to have tear-downs and stuff so we can properly shut down tests.

Hey @nkcmr.

How are you?

After so many years, in Node.js ecosystem I don't see yet a solution like flic.
I know seneca and moleculer, but really I like the minimalist approach of flic.

I would like to outline the roadmap for a new version, maybe v2.0.0.

I propose here the completion of the following items (intending I will try to implement them):

• [Issue] wildcard tell calls
• [Issue] allow control over bridge listening
• [Issue] List of node names
• [Issue] Host configuration
• [CI/CD] move from Travis CI to GitHub Actions (just to reduce the environment complexity)
• [Deps] remove lodash and uuid deps (just to lower the external dependency)
• [Test] add benchmark to measure messages throughput (just to mark a set point and to see the diffs in next versions)
• [Lint] Add eslint

What do you think?

there is no reason why node names should be validated, it is just unnecessary overhead.

Calling flic.createNode(err => { ... }) fails with:

port should be a number or string: err => { ... }
    at lookupAndConnect (net.js:927:13)
    at Socket.connect (net.js:906:5)
    at Object.exports.connect.exports.createConnection (net.js:63:35)
    at Node._connect_bridge (/home/paul/workspace/blinkstick/node_modules/flic/lib/node.js:64:22)
    at new Node (/home/paul/workspace/blinkstick/node_modules/flic/lib/node.js:51:8)
    at Object.exports.createNode (/home/paul/workspace/blinkstick/node_modules/flic/lib/flic.js:6:10)
    at Object.<anonymous> (/home/paul/workspace/blinkstick/start.js:4:17)
    at Module._compile (module.js:398:26)
    at Object.Module._extensions..js (module.js:405:10)
    at Module.load (module.js:344:32)

The cause appears to be that the Node constructor is checking whether the passed config is an object, but _.isObject returns true for all non-primitives (including function).

a real handy feature would be the ability to address multiple nodes, sort of like a limited shout. follow along:

var x = new Node('web-worker')
// ... later on
x.tell('cache-worker-*:clear') // tell all cache-workers to clear cache

if there are three nodes sending messages at the same time to a single node, then while the first .on 'data' event is being handled, the other two messages are added to the stream, thus the next 'data' event will return a concatenated string, which will be ignored, because that can't be json parsed.

In Node constructor there is an attempt to handle the old interface with id and callback with the new one, the config object.

The point is createNode passes only the first parameter, in this case id, vanishing the use of arguments in Node constructor.

I think the arguments trick should be done there and not in Node constructor: it is too late.

Indeed if I try to use the example contained in the README, it doesn't work.
Using the new interface and passing the config object with id and connect_callback it works nicely.

Luckly, my old code used require("flic").node and I didn't notice any problem.
After upgrading the code with createNode, the app stopped to work correctly.

What do you think about providing the list of node names connected to the Bridge?

I have been developing a graphical interface listing the nodes.

Another approach would be adding a callback to the shout API: every node may return any message, for instance a string containing the name of the node, and the "master" node might collect it.