We've dived deep into a pool of real-time world applications working with ever-updating data. If you're a web developer or know how HTTP requests work, you know that real-time data isn't possible with the conventional web.

History of web

The web created using HTTP protocol made the interaction between the web and the user in 4 simple steps-

• Open a connection
• Send a request
• Receive response
• Close the connection

It worked well initially, letting two nodes communicate over the internet. Since it was all stateless, even if the connection dropped, you could restore the communication from that very point.

However, as we move towards real-time applications we need to ensure minimal latency sharing of data just as it is created in the real world. To do this with conventional HTTP cycles is a huge overload as multiple cycles lead to more latency since each of these cycles requires a new connection to be set up every time.

To minimize these cycles while keeping the data flow the same Long-polling was introduced.

With Long-polling the connection set up in a traditional request-response cycle could be persisted for a little longer i.e. the server has an opportunity to collate more than a single piece of data to send back in a single response and it also eliminated the case of empty response as the server could just return a response when it has some data to give back.

But even Long-polling involved the setup and frequent request-response cycles creating latency. Which wasn't suitable for real-time applications where the speed of data up to the nearest millisecond is critical.

This led to WebSockets, which unlike HTTP is a stateful protocol that works over TCP. The communication starts as an HTTP handshake but if both the parties agree to continue over WebSockets, the connection is then elevated to a full-duplex, persistent connection i.e. the connection stays open for the complete duration that the application is running, this gives the server a way to initiate a conversation to the pre-subscribed clients rather than waiting for a request-response cycle to be initiated by the client about the availability of new data.

From the above arguments we can see that WebSockets have a defined advantage over the conventional HTTP cycle.

Does that mean we should not use HTTP anymore? NO.

HTTP vs WebSockets

Even with the added advantage of WebSockets, they aren't always the better choice.

Here are a few scenarios where HTTP is better

• The client wants the current state of a resource and doesn't require ongoing updates
• For highly cacheable resources i.e. the resource either doesn't change at all or changes very rarely
• Where Idempotency and safety are critical. HTTP methods have broadly shared safety and idempotency expectations. The WebSocket protocol leaves these issues to the messaging layer design
• Error handling is required. HTTP has extensive support for errors describing the errors with the request, response or providing status information to differentiate between success scenarios. While the WebSocket protocol only provides support for errors regarding the establishment of the connection.

Just as HTTP there are scenarios where WebSockets are a better choice

• When a user is required to react quickly to a change, for example, a chat application.
• When a user wants ongoing updates about the state of a resource, for example, an ongoing football match
• When there's a high frequency of messages between the client and server with small payloads

Libraries

Here are a few Node.Js libraries that use WebSockets you can use in your next real-time projects -

• SockJs
• ws
• Socket.IO
• Faye WebSocket
• SocketCluster

This is just the tip of the iceberg when it comes to real-world real-time applications, a lot of other things going on behind the scenes. You can dive into the article inked here, which talks about the history of the internet protocols, the people behind their creation, motivations behind conceptualizing these protocols, open-source solutions that you can implement for free and also taking it to the next level by adding scalability, etc.

Happy Coding!