The exploding world of real-time data integration has led many to ask what technologies represent the best choice for their application architecture and how real-time data delivery platforms can help. There are several competing vendors – but not all are created equal. In this post, we’ll discuss the differences between Server-Sent Events and the WebSocket protocol.

First-off, for many the term Server-Sent Events (SSEs) may be unfamiliar. For the past few years the specification has been in a state of flux and has definitely been overshadowed by the more fully featured communication protocol – WebSockets. However, the idea behind SSEs should be familiar: allowing a Web Application to “subscribe” to data updates originated (sent) by a server, and subsequently been notified as these data events occur.

Of course, WebSockets provide a richer protocol to perform bi-directional, full-duplex communication. Having a two-way channel is more attractive for things like games, messaging apps, collaboration tools, interactive experiences (inc. micro-interactions), and for cases where you need real-time updates in both directions.

But to really understand real-time technology, we need to discuss the limitations of its predecessors, which includes:

Polling is used by the vast majority of applications today. In this model, the client application repeatedly polls a server for data. Based entirely on the foundations of the Web, these applications leverage the HTTP protocol, that allows the fetching of data in a request/response pattern. The application asks (requests) the server for data based on some query parameters, and waits for a response which is often of unknown size. If no data is available, an empty response is returned. The problem here is that empty responses, or multiple responses containing duplicate data cause a huge amount of overhead.

Long polling is a variation of polling designed to accommodate scenarios where the server does not have new data available. When an HTTP request is received the server will hang on to the connection until new data does become available, the server responds, closes the connection, and the process is repeated. This creates the effect of event-based responses, but in reality this is a costly hack.

WebSocket vs Server-Sent Events

A WebSocket connection can both send data to the app and receive data from the app. A true interactive experience relies on this 2-way exchange of data in real-time. Server-Sent Event connections on the other hand can only push data to the app, and do not offer any communication in the other direction.

In practice then, everything that can be done with SSE can also be done with Websockets, and so has received far greater support, attention and adoption – with many more browsers and devices supporting Websockets than SSEs.

Real-time Messaging

Here at Push, our Real-Time Messaging technology relies on the WebSocket protocol as our first choice for real-time data delivery. However, we have abstracted the data transport away from developers so that there is no need to learn a new technology or support a new WebSocket server. If for some reason the WebSocket protocol is unavailable, we can automatically fallback to various long-polling options.