I think it's more like Hook.io than Socket.io. One use could be server monitoring or deployment. You can also check out the Hook.io hook libraries to see how that has been used: https://github.com/hookio/hook.io/wiki/Hook.io-Libraries

This seems like a simpler API to me.

Thanks for the reply, I'll check out Hook as well.

I'm fairly new to working with Node, so any kind of context for use-cases around some of these libraries is always a help

i assume messenger works the same way, but the nature of hook is the processes are completely decoupled. essentially, you are just creating an event emitter that works cross-process. one benefit of this decoupling is it enables you to spin up and take down these processes without affecting the rest of the program.

Personally, I have a scraper service, web app server cluster, stream server cluster, mobile service, and a data access layer in my setup.

They all communicate with each other, but in very different ways.

The scraper for example uses fire and forget to send something to the data access layer.

The web app cluster needs to use the request reply model with the data access layer.

The data access layer needs to send pub / sub messages to the stream clusters holding live connections.

I also have a mobile service which does a combination of pub / sub (notify stream servers), req / rep (data access), and fire / forget (analytics).

I needed one library with a 1 line install that handled all of these cases, with the simplest API I could come up with.

I originally built node-monitor (https://github.com/franklovecchio/node-monitor/tree/v0.5) to monitor multiple servers; I was trying to emulate Splunk by sending all data from an environment to a couple servers, which then pushed out to websockets (live log viewing) + POSTed to CloudWatch. Ended up throwing out the socket piece because it was a pain in the ass to manage.

On a side note, you can scale what would be single-instance architecture with something like messenger (think an MQtt.js broker).