Real-Time Web with JavaScript — I

Ayoub NEJJARI
The TechCave
Published in
6 min readJun 11, 2017

--

“The Real-time Web”, a term coined few years ago to describe a live web, where data exchange and communication happen in real time and instantaneously. This trend continued growing, and still, in a world where people became impatient and can’t stand delays and where businesses’ survival and even growth depend on getting data as fast as possible and before everybody else.

Big companies like Google and Facebook were the major pioneers to integrate real-time services in their systems. Notifications and instant messaging are examples of real-time web.

If you are a developer, and has been for while in the field, it’s more likely you know the term and the mechanics behind it. Maybe you have even built real-time web apps. Whether you are new to the concept or familiar with it. This post, will introduce you to this very important concept, or simply refresh your mind about it. The next two, will go more in depth with real world examples. Either way, I’m sure you won’t waste your time.

To understand Real-time web, know how it works under the hood, and build the proper mental model of it, which all three elements are required if you ever wanted to build a real-time web app. To do that, it’s necessary to talk about how communication over the web evolved to what it is now, and of course, that will also help you understand what it will become in the near future, because we’re about to enter a new era of the Web.

The Traditional HTTP Communication Model

Traditionally, communication over the web has been possible thanks to the HTTP protocol. The most common architecture is the client/server one, in which the client would send and HTTP request to a server, the server then processes the request and respond with an HTTP response. There is one problem with this model though. The HTTP protocol is a stateless, connection-less protocol, and if you don’t know what that means, take a look at my video about HTTP, it will take you less than 1 min. With this model, we can’t even talk about dynamic websites, let alone real-time apps.

AJAX to the rescue

Then, Superman of the web came to save the day, AJAX. With this technology, new kind of websites were introduced, which was a real revolution, dynamic websites. But there is a truth that few people know. AJAX made it feel dynamic, but it wasn’t “really” dynamic as it seemed. Behind the scenes, it’s just HTTP requests and responses that made it possible, the difference is that AJAX takes care of that in the background without letting the user see it, which is awesome of course. Gmail was one of the first users of AJAX technology. But still, if the server got additional data, there was no way of notifying the client about it at the time. Which is why new technologies emerged. Actually, not entire technologies, just hacks and workarounds to simulate “real-time” web.

1 - Polling

This technique uses JavaScript in the background to make requests to the server at regular intervals. Just asking the server for data over and over again. In which, most of the times the response contains no data. Yes, it was more close to real-time than previous methods. But if you see it from another perspective, it introduced many problems, the biggest ones were of performance and latency. Because of the nature of HTTP, servers suffered from the huge number of requests and request processing and the overheads of TCP handshakes and unnecessary information every time, HTTP headers.

2 - Long Polling

This is just as the previous one. The difference is that when the server receives a request, it doesn’t respond immediately. Instead, it waits until there is really new information, then sends back the response. After that, the client initiate a new connection and sends a request, and the same process repeats over and over again. This reduced the number of requests and eliminated some issues, but it didn’t really solve the real-time problem.

3 - Comet Techniques

These are unstandardized hacks that use polling in combination with other technologies to achieve real-time experience.

Other methods have been used such as Java plugins for server push which is a better technique that allow servers to open TCP socket connections with clients and push data in real-time. The problem was that those plugins had to be installed and if they did, they faced security issues.

Retrieved from http://journal.frontiersin.org/journal/communication

WebSockets, The Real Superman

Alright, real solutions came to existence! No more hacks, no more workarounds. Yaay!

WebSockets provides a bidirectional full-duplex sockets over TCP. In other words, they provide a persistent connection between the client and the server that they can both use to send and receive data in real time, anytime.

Wait mate! What is a WebSocket?

WebSockets are part of HTML5 Spec, they are a communication protocol that operates over TCP, just like the HTTP protocol and other TCP-based protocols. They are refered to as ws or wss for secure websockets, just like HTTP and HTTPS. WebSockets are meant to be implemented in web servers and web browsers to allow the real-time experience.

Now tell me how It works.

Retrieved frpm https://www.linkedin.com/pulse/websockets-vs-rest-understanding-difference-joe-hanson

At first the client must initiate the connection with the server via an HTTP request. Once the connection is established, the client will send another HTTP request with an ‘upgrade’ header informing the server that the client wants to establish a webSocket connection. If the server approve, the connection establishes via a process known as the websocket handshake. As simple as that!

This is how the HTTP request, with few headers, would look like:

GET ws://websocket.com/ HTTP/1.1
Connection:upgrade
Host:websocket.com
Upgrade: websocket

If you’ve noticed, the ws scheme is used instead of http or https. That’s how websockets work. Now, messages between the client and the server can be exchanged back and forth in real-time without any problem. No HTTP headers overhead, no latency problems.

“Reducing kilobytes of data to 2 bytes…and reducing latency from 150ms to 50ms is far more than marginal. In fact, these two factors alone are enough to make Web Sockets seriously interesting to Google.” — Ian Hickson, the HTML5 specification lead.

Now that you know what real-time web means and how it is possible with WebSockets, in the next article, the second one, I will deep dive into the inner workings of it in order to have a solid and better idea, and I will include an example with JavaScript. In the third part, we’ll be exploring SocketIO and the magic it provides.

Stay Tuned!

Thanks for taking the time and reading! If you liked it, please hit the hear button and share it so others can find it! ^^

--

--