Express vs Socket.io

Question

I have just began using socket.io and I have some experience with express. I know socket.io has bidirectional communication while express is only client to server.

This made me think, why don't we just use socket.io with different namespaces and not use express at all?

In which cases should I use socket vs express?

In the case I need bidirectional communication, is it advisable to make the client -> server with express and then use socket for server -> client?

Answer 1

First off express and socket.io are pretty different things. Express is a full-blown web server framework. You use it for setting up a web-site, fielding http requests from a browser, fielding http requests for an API, etc...

socket.io is a communication layer that sits on top of the webSocket protocol and the webSocket protocol uses an http server to establish its initial connection. While there is a little bit of overlap between what you can do with socket.io and Express, they are more different than they overlap.

For example, if you're setting up a web-site, you couldn't do that with socket.io, one would use something like Express.

Now, if you have a specific programmatic need to communicate between an arbitrary client and a server, you have a zillion choices. If the client is in a browser and the programmatic interface is from Javascript in the browser, then you have fewer choices. From the browser, using http ajax requests via Express is one choice. Setting up a socket.io connection and defining you own messages is another choice.

Reasons to pick socket.io over Ajax calls to Express from browser Javascript:

1. You need/want two-way communication over the same channel.
2. The client is sending a lot of requests to the server (the overhead for sending a socket.io message is lower than an ajax call, once the socket is already set up, so if you're sending a lot of messages, then socket.io messages are more efficient than http requests)

Reasons to pick Ajax calls to Express:

1. HTTP connections are stateless and short-lived which can make implementing high scale, multi-server implementations with failover and redundancy easier.
2. There are a wealth of tools to use for http connections from authentication libraries to data formats (MIME) to audio to video, etc...
3. You want your client to run in places where a long-connected socket.io during inactive periods of time may not be practical (perhaps mobile or battery operated devices).
4. You want to run in situations where there are proxies, firewalls or other network infrastructure that may not support long running webSocket connections or specifically disallow them.
5. You want a request/response model. HTTP is request/response where you get a specific response for each request and you know exactly which response goes with which request.

So, as you can see, there is no generic answer to this question. It really depends upon the specific of your communication, the interoperability you desire and the exact needs of your code.

Here are some other references on this topic:

Ajax vs Socket.io

Websocket vs REST when sending data to server

Using AJAX vs. socket.io socket messages

websocket vs rest API for real time data?