It is interesting to create a new node app to handle socket.io?

Question

I want to add on an existing project some sockets with nodeJs and Socket.io. I already have 2 servers :

• An API RESTful web service, to storage and manage my datas.
• A Public web service to return HTML, assets (js, css, images, ...)

On the first try, I create my socket server on the Public one. But I think it will be better if I create an other one to handle only socket query.

What do you think ? It's a good idea or just an useless who will add more problem than solve (maybe duplicate intern lib, ..)

Also, i'm using token to communicate between Public and API, do I have to create another to communication between socket and API ? Or I can use the same one ?

------[EDIT]------

As nobody didn't understand me well I have create a schema with the infrastructure I was thinking about.

1. It is a good way to proceed ?
2. The Public Server and Socket server have to be the same ? Or can be separate ?
3. Do I must create a socket connection between API and Socket server for each client connected ?

Thank you !

Answer 1

Thanks for explaining better.

First of all, while this seems reasonable, this way of using Socket.io is not the most common one. The biggest advantage of using Socket.io is that it keeps a channel open for 2-way communication. The main advantage of this is that the server itself can send messages to the client without the latter having to poll periodically.
Think, for example, of a mail client. Without sockets, the browser would have to poll periodically to check for new mail. With an open socket connection, instead, as soon as a new mail comes the server notifies the client immediately.

In your case, the benefits could be limited, and I'm not sure the additional complexity of a Socket.io server (and cost!) would really be worth the modest speed improvement on REST requests. However, at the end it's up to you.

In answer to your points

1. See above
2. If the "public server" is not written in Node.js they can't be the same application. Wether they reside on the same server, it's up to you and your budget. Ideally they should be separate, for bigger workloads.

3. If you just want the socket server to act as a real-time proxy, then yes, you'll have to create a socket connection for each request. How that will work is:

   1. The client requests a resource to the Socket.io server.
   2. The Socket.io server does the normal HTTP request to the API server (e.g. using request)
   3. The response is returned to the client over the socket connection

The workflow represented in #3 is the reason why you should expect only moderate performance improvement. Indeed, you'll get some better latency, but most of the overhead for starting a HTTP request is still there!