In this article I hope to provide insight on Web Sockets and their importance in modern applications that are built with necessity for real-time data.
In this quick reading we'll cover the differences between using WebSockets and a RESTFUL approach in an application.
After this reading I hope you will be better aquainted with the topics of:
WebSockets use a data-transfer system which we call bi-directional messaging, or we can think of it as a "persistent and open connection". In the case of a chat app, we would want to use Websockets to keep the connection open so that messages can be sent and recieved instantly over the duration of the conversation.
In my first example I'll use a diagram to visualize a REST data-transfer system that will utilize a basic, GET request made from client to server and then an additional diagram of a basic Web Socket connection so we can compare the difference between both.
When using REST in our applications, everytime a GET request is made we can imagine that as picking up the phone and calling to check if any information is available.
But regardless if information is available, we end the call. To dive a bit deeper into this idea, in the case where no information is retrieved, the request will still send unnecessary data back and forth everytime a request is made, this carries alot of "unseen" baggage in the application. And if our goal is to only retrieve the data when we need it, the REST approach may not be our best option.
QUEUE WEBSOCKETS
Instead, websockets use a "persistent connection" system where when the client first establishes a connection with the server (connects to the page), the connection stays live and when data is recieved, its instantly communicated to the client from the database. I've provided a visual of this below:
This may seem very similar to AJAX , introduced in 2005 and was quite groundbreaking in web-development at the time because it opened up the possibilites of having bi-directional connecting between client and server.
Another popular method introduced not long after was known as "long-polling". This involved keeping the HTTP connection open until the database had data to give to send to the client however, one major issue in both of these methods is that they carried the overhead of HTTP.
With all of the headers, data and cookie information involved in a HTTP request, you can imagine, this created alot of latency and caused applications to run quite slow. In the case of a browser-based game, it was deemed unacceptable and this is why websockets which don't use http came into such popularity.
Here is a visual of a basic websocket request, and response.
Notice the "ws://" Instead of typical "http"?
Just like http websocket has its own secure connection
ws = websocket
wss = websocket secure
Below, I've supplied a list of popular WebSocket Libraries which all support NodeJS:
Pusher is a hosted service that sits as a layer between client and server in our applications. It handles all requests sent and received from client and server and creates an open and maintained connection (aka handshake) with every client that visits the app. I've put a visual below:
In many cases Pusher is used by Trading applications that require instantaneous real-time results, delivery services that display a realtime location of your delivery and social networks that support realtime live comments. In conclusion, API's such as Pusher are great for utilize the power of websockets with much more ease,
and cuts the time developers spend managing.
Pusher supports many frameworks such as:
Thanks for reading, I hope this leaves you with a better understanding of websockets, how they work, and some great libraries to play around with.
A great article I'll leave you with is one from hackernoon going over REST, WebSockets and HTTP.
