The web is huge and it is fundamental for any business operations in the modern day. When we speak about web architecture, the picture that gets drawn is a request/response flow from a client to the server. A user navigates to the webpage on the browser and initiates a server communication. The server then does its magic and responds with all the flavors required to attract the end user’s attention. This has been the benchmark since the web was first invented back in August 6, 1991, A project created by Tim Berners-Lee. It ran on a NeXT computer at the European Organization for Nuclear Research, CERN and the world’s first website was called http://info.cern.ch/hypertext/WWW/TheProject.html
Fair Enough! Now around the 2000’s, AJAX started to make the web feel more responsive and dynamic. But still, all communications were steered by the client. This required periodic polling to load new data from the server.
Have you come across terms like “Push” or “Comet”? One of the most common cheat code to create the illusion of a server initiated push/connection is called a long polling. With long polling, the frontend or the browser opens an HTTP connection to the server and keeps it open until a response is received. Whenever the server gets new information it triggers a response to the client. There are also other cliche techniques in the market like Flash, XHR multipart and htmlfiles. Some softwares like Gmail chat, Facebook use long polling predominantly in their applications.
The hard downside here is these tools carry the overhead of HTTP, which isn’t a great contender for low latency applications. There is an increased latency with the continuous transmission of data to the front-end. Rules have to be enforced in such a way that these connections do not stay alive permanently, this may cause constant re-connections. This also leads to significant investment on resources.
Enough with our history lesson!.
WebSockets
WebSockets add more fluidity in solving this problem. The obvious number one advantage is that it eliminates latency which is a common scenario with long polling. In webSockets, an initial handshake happens between the client and server and this keeps a unique persistent connection open. It is not a game changer but it definitely gives us something to work with. It also eliminates additional overheads. Here is a small snippet of a WebSocket implementation in NodeJS:
const socket = require('ws'); // node WebSocket libraryconst ws = new socket('ws://www.server.com/path');
ws.on('open',() => {
ws.send('send it');
});
ws.on('message', (data) => { //incoming
console.log(data);
});
Looks simple?, Well although we can implement our own vanilla WebSocket, there are a few libraries that takes care of a few heavy lifting. For instance: Socket.io, WebSocket-Node, Faye.
One Big player and most popular tool who also include WebSocket in their arsenal is GraphQL. They enforce this in the name of subscriptions. We have heard about queries and mutations, but subscriptions are a third powerful operation supported by it. Unlike queries or mutations, subscriptions are long-lasting operations that can change their result over time. They can maintain an active connection to the server (via WebSocket), which enables the server to push updates to the subscribed client.
In our next post, Let’s build a server client subscription application. We will be using Apollo client which is a very close friend to our popular ReactJS framework. It is a comprehensive state management library that enables you to manage both local and remote data with GraphQL. We will be using ReactJS for our front end and NodeJS for our backend. We will witness the subscription mechanism in action. Follow Along!
