WebSocket and Real-Time Web Features

Photo by Neven Krcmarek on Unsplash

As a casual user of the modern Web, it’s easy to take for granted just how many applications and websites have real-time features. Users expect their pages to update and change quickly and intuitively as they use them. Facebook should show chat windows and notifications alongside static content; email accounts should update with new messages without refreshing the page; a chat window should always be available for a user to get help.

As web developers know, these features require a different approach from hypertext transfer protocol (HTTP) functionality, where a client sends a request to a server and waits for a response. Imagine, for example, a chat window that requires users to click a “Fetch Messages” button to get each new message. Certainly that’s not an ideal user experience — there’s got to be a better way!

Don’t let YOUR website be the reason users make this face.

In this article, we’ll briefly discuss the history and basics of WebSockets, describe a few WebSocket libraries, and finally zoom out a bit more to look at purchasable, fully-managed real-time web solutions.

TCP and HTTP Long Polling

Before WebSockets, there already was a way to establish real-time connections. HTTP already uses transmission control protocol (TCP), which supports sustained, two-way communication between server and client. HTTP, however, specifically enforces request/response communication, and HTTP is also the method websites are accessed with. TCP could be used for standalone real-time applications, but not real-time websites running in a browser.

For years, developers used a workaround known as “long polling” to create real-time features in web browsers. Long polling still uses HTTP, but it stretches the definition of a request and a response. Here’s how it works:

1. The browser sends a request to the server.
2. Rather than immediately sending a response, the server leaves the connection open and waits until it has a message to send.
3. When the server has a message, it sends it to the client and closes the connection.
4. The browser receives the message and immediately sends another request.

This works, but it requires the server to handle many “hanging” connections. It also involves a fair amount of overhead for every message sent and received, since each message still requires the full request/response workflow.

There STILL has to be a better way!

HTTP long polling: it gets the job done, but it’s definitely not how the tools were designed to be used.

Enter WebSockets.

WebSockets

WebSockets, similar to HTTP, are a wrapper around TCP. However, instead of enforcing request/response communication, WebSockets bring the sustained two-way communication features of TCP to browsers without requiring extra plugins or support. WebSockets are event-driven, meaning that developers can assign meaningful categories to messages from both the server and the client and respond appropriately in each case.

WebSocket connections aren’t completely separate from HTTP, however. WebSockets still rely on an initial HTTP connection from a client to a server. Once the connection is established, WebSockets allow the client to negotiate with the server to use the WebSocket protocol and open a long-term TCP-like communication channel.

WebSockets are a low-level tool, and as such they have a variety of uses. WebSockets can drive live chat, notifications, location tracking features, multiplayer games, live collaboration sessions, and more! They’re a flexible tool that can be used for many purposes.

WebSocket Libraries

Naturally, developers were not content with just the base WebSocket toolkit. There are many popular real-time libraries that make WebSockets easier to use or add helpful features. You can find a helpful list here, but I’ve chosen a few to summarize here.

• ws describes itself as “a simple to use, blazing fast, and thoroughly tested WebSocket client and server implementation.” It abstracts away some of the more technical details of making a WebSocket connection without adding extra overhead.
• Socket.io is an open-source Node library that adds helpful features such as namespacing, support for “rooms” to group connections, and automatic fallback to HTTP long polling if it’s unable to make a WebSocket connection.
• µWebSockets is an open-source Node library written in C and C++ with dedicated customer support. It focuses on speed, security, and scalability, and includes built-in routing capability.

Managed Solutions

Some businesses and users may want to take the additional step of paying someone else to handle infrastructure and maintenance. There are multiple software-as-a-service (SaaS) solutions for real-time applications available, each with a variety of features and pricing options. Services such as Pusher, Ably, and PubNub supply the infrastructure necessary to handle real-time connections for enterprise-level software. By connecting an application to their API, users can reliably send and receive millions of messages per second to and from their clients without needing to set up or maintain the necessary hardware.

Wrap-Up

As a modern web developer, it’s important to be prepared to deliver the real-time functionality most users expect from web applications. Whether you choose to use a managed service, a standalone library, or the raw toolset itself, WebSockets are at the core of delivering a reliable, fast real-time experience.

References

I used the following articles and StackOverflow responses when researching this article:

• What is the fundamental difference between WebSockets and pure TCP? (StackOverflow)
• The WebSocket API (MDN)
• Long Polling (Javascript.info)