CODEWITHSUNDEEP
node.jssocket.io
cheng
cheng

Reputation: 1324

Best way to connect 2 separate node processes with socket.io communicating to a client

I'm new to working with sockets and have a small system design question:

I have 2 separate node processes for a web app, 1 is a simulator that is constantly running and the 2nd is an api server. Both share the same MongoDB database and we have a React app running for the client, served by the api server.

I'm looking to implement socket.io for real-time notifications and so I've set up a simple connection between the api and client.

My problem is that while the simulator runs, there are some events that I also want to trigger push notifications for so my question is how to hook that into everything?

The file hierarchy is like:

app/
  simulator/
  api/
  client/

I saw this article for communication between node processes and I currently have 3 solutions in mind:

  1. Leave hierarchy as it is and install socket.io package inside simulator as well. I'm not sure if sockets work this way but can both simulator and api connect to the same socket?

  2. Move simulator file into api file to fork as a child process so that the 2 processes can communicate via child/parent messaging. simulator will message api which will then emit updates through the socket to client

  3. Leave hierarchy as is and communicate via node-ipc. Same situation as above with simulator messaging api first before api emits that to client

If 1 is possible, that seems like the best solution in my impression. It seems like extra work to add an additional layer of messaging for 2 and 3.

Upvotes: 0

Views: 1526

Answers (2)

serguitus
serguitus

Reputation: 526

You should check Socket.IO docs about adapters and Emitters. This allows to connect to sockets from different node processes and scalability.

Upvotes: 0

jfriend00
jfriend00

Reputation: 707278

Leave hierarchy as it is and install socket.io package inside simulator as well. I'm not sure if sockets work this way but can both simulator and api connect to the same socket?

The client would have to create a separate socket.io connection to the simulator process. Then, the client can receive data from the API server over one connection and from the simulator over another connection. You would need two separate, independent socket.io connections from the client, one to the API server and one to the simulator. Simulator and API server cannot share the same socket unless they are in the same process.

Move simulator file into api file to fork as a child process so that the 2 processes can communicate via child/parent messaging. simulator will message api which will then emit updates through the socket to client

This is really part of a broader option that the simulator communicates with the API server and sends it data that the API server can then send to the client over the single socket.io connection that the client made to the API server.

There are lots of different ways for the simulator process to communicate with the API server.

  1. Since it's already an API server, you can just make an API for this (probably non-public). The simulator calls an API to send data to the client. The API server receives that data and sends it to the client.

  2. As you suggest, if the simulator is run from the API server as a child process, then you can use parent/child communication messaging built into node.js. Note, you don't have to move the simulator files into the API file at all. You can just use child_process to launch the simulator as another nodejs app from another project. You just have to know the path to that other project.

  3. You can use any another communication mechanism you want between the simulator process and the API server process. There could be a socket.io connection between them. You could use several forms of IPC, etc...

If 1 is possible, that seems like the best solution in my impression.

Your #1 option is not possible as separate processes can't use the same socket.io connection.

It seems like extra work to add an additional layer of messaging for 2 and 3.

My options #1 and #2 are not much code in each server. You're doing interprocess communication. You should expect to use some code to enable that. But, it's not hard at all.

If the lifetime of the simulator server and the API server are always together (they have no independent uses), then I'd probably do the child process thing where the API server launches the simulator and then use parent/child messaging to communicate between them. You do NOT have to combine sources to do this. The child_process module can run the simulator process by just knowing what directory it is located in.

Otherwise, I'd probably make a small web server on a non-public port in the API server and have the simulator just send data to that other web server. I often refer to this as a control port. It's a way of "controlling or diagnosing" the API server internals and can only be accessed from within the private network and/or with credentials. The reason I'd use a separate web server (in the same nodejs app as the API server) is to make it easy to secure so it can't be accessed from the outside world like the regular public APIs can. You just put the internal web server on a port that is not exposed to the outside world.

Upvotes: 1

Related Questions