Question

At the moment, I am using EventEmitter2 as a message bus inside my application, and I really like it.

Anyway, now I need a message bus which does not only work in-process, but also inter-process. My ideal candidate would …

  • … be API-compatible to EventEmitter2 (a "drop-in replacement"),
  • … work without a dedicated server or external service (such as a database, a message queue, …), only using OS resources,
  • … be written in pure JavaScript,
  • … run in-memory, so it does not require persistence.

What I do not need:

  • It does not need to run on Windows, OS X and Linux are fine.
  • It's okay if it works only on a single machine, it does not need to be network aware.

Any ideas or hints?

PS: It is fine if you can recommend an available product, but it is also fine if you can point me into a direction of how to do the server-less thing by myself.

Was it helpful?

Solution

Here are your options as I see them.

  1. process.fork/send. If both processes are node, node core provides a simple, event-driven IPC mechanism via this API. It pairs with process.fork so if your processes are a node-based master and several node-based worker/support subprocesses, process.send might be a viable choice. http://nodejs.org/docs/latest/api/all.html#all_child_process_fork_modulepath_args_options

    • event-based, but not EventEmitter2 drop-in
    • bi-directional
    • efficient
    • uses only OS resources
    • in-memory
    • javascript
  2. Use node core's TCP networking to connect via a unix domain socket. http://nodejs.org/docs/latest/api/all.html#all_net_connect_options_connectionlistener

    • still event based but raw data stream as opposed to high-level messages
    • bi-directional
    • in-memory
    • javascript
  3. Good old TCP.

    • still event based but raw data stream as opposed to high-level messages
    • bi-directional
    • in-memory
    • javascript
  4. node-to-node socket.io

    • event based, but not EventEmitter2 drop-in
    • bi-directional
    • in-memory
    • javascript

In all cases you get bi-directional communication once connected, but there is always the concept of the first peer (server in TCP or socket.io, parent process in process.fork) and second peer (client in TCP or socket.io, child process in process.fork).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top