1

There will be no human being in the loop, and both endpoints are autonomous Node.js applications operating as independent services.

Endpoint A is responsible for contacting Endpoint B via secure web socket, and maintaining that connection 24/7/365.

Both endpoints will initiate messages independently (without human intervention), and both endpoints will have an API (RESTful or otherwise) to receive and process messages. You might say that each endpoint is both a client of, and a server to, the other endpoint.

I am considering frameworks like Sails.js and LoopBack (implemented on both endpoints), as well as simply passing JSON messages over ws, but remain unclear what the most idiomatic approach would be.

Chris
  • 824
  • 1
  • 7
  • 26
  • Are you looking for pub/sub functionality? Where something like ActiveMQ/RabbitMQ or even Redis could suffice? A messaging queue would also let you scale the servers horizontally. – Jason Kulatunga Jul 29 '14 at 04:53
  • Endpoint A already uses a message queue for a different use case, but in this case, the web socket is required because the connection serves as a 'heartbeat' of sorts - a "Yes, I'm still here" signal in real-time. Also, the communication is fully bidirectional between both endpoints. – Chris Jul 29 '14 at 15:49

1 Answers1

0

Web Sockets have a lot of overhead for connecting to browsers and what not, since they try to remain compatible with HTTP. If you're just connecting a pair of servers, a simple TCP connection will suffice. You can use the net module for this.

Now, once you have that connection, how do you initiate communication? You could go through the trouble of making your own protocol, but I don't recommend it. I found that a simple RPC was easiest. You can use the rpc-stream package over any duplex stream (including your TCP socket).

For my own application, I actually installed socket.io-client and let my servers use it for RPC. Although if I were to do it again, I would use rpc-stream to skip all the overhead required for setting up a Web Socket connection.

Brad
  • 159,648
  • 54
  • 349
  • 530
  • Hi Brad. I appreciate the response. It's a great idea, but WebSockets is a requirement because HTTP(S) is the only option available. There will be multiple firewalls between the two endpoints, so the only ports I can count on are 80 and 443, and for security reasons, only 443 is really an option. – Chris Jul 25 '14 at 17:41
  • @Chris These are intelligent firewalls? If it's just ports, you can make a connection over port 80 and 443 and run your own traffic over it. If it must be Web Socket, I recommend using Socket.IO and the socket.io-client package. That's easy to get working out of the box. – Brad Jul 25 '14 at 17:52