Question

I want to ask about some good practices. I have a Node.js (Express) web server and socket.io push server (in case technology matters). I can turn both of them into one application but I want them separated (they can communicate with each other if necessary). There are two reasons to do that:

1. It will be easier to manage, debug and develop the app;
2. It will be a lot easier to scale the app. I can just add another instance of push server or web server if necessary;

This is at least what I believe. The only problem is that when a client connects to the seperate socket.io server then it won’t send cookies (different port, cross-domain policy).

The workaround I came up with is to put a reverse proxy (written in Node.js as well) in front and check what kind of request we are dealing with and send it to web server or push server accordingly. Great, now we have cookies in both web server and push server. The reverse proxy can be a load balancer which is an additional bonus.

It looks like a good idea to me. What do you think about this design? Perhaps any other workaround for cookie problem?

Answer 1

I recently did something simular, we initially used a node.js reverse proxy but ran into reliability/scalability problems. We found serving static files and proxying requests was best left to nginx. haproxy is also a very viable solution for stand alone proxying as well.

HaProxy
Nginix as a reverse proxy