Some kind of real-time communication is required in almost every modern application. It can be used to build a data feed like twitter posts or stock market prices, a chat, a notification system, etc… Nowadays the goto solution to implement these features is WebSockets. In this post I will argue that Server-Sent Events are better in most cases.

This is obviously an opinion post. It is based on my experience as a full-stack developer and cannot be devoid of personal biases or even mistakes. I know I’m right, but feel free to disagree. I like debates :)

WebSockets

The WebSockets interface allows web applications to maintain a bidirectional communication channel with a server. Although they are an abstraction over the HTTP protocol, WebSockets connections are actually performed through their own protocol. It uses ws and wss url schemes instead of http and https. The WebSockets protocol provides an easy to use and widely available streaming mechanism since its standardization in 2011.

How does it work ?

A WebSockets channel is initialized through an HTTP handshake. The HTTP connection is upgraded to a WebSocket connection if it succeeds. Then the data is transferred over TCP in both directions until the connection is closed.

Server-Sent Events

SSE provides real-time updates from a server through an HTTP connection. It was first proposed in 2004 and is now part of the HTML standard which defines a specific text/event-stream HTTP content type.

How does it work ?

An HTTP request is made for a text/event-stream resource. The connection is maintained and events are streamed through to the client until it is closed.

WebSockets and SSE are competing technologies

These two technologies allow web applications to receive real-time updates from a server. A feature that could not be implemented following the basic web standard without some serious hackery. This is because the web has been built as a request-response model. In a web setting a client typically makes a request that is then processed by a server which sends a response thus ending the interaction. WebSockets and Server-Sent Events both solve the same basic problem.

Why WebSockets are generally preferred over Server-Sent Events ?

WebSockets is a more recent and powerful technology than Server-Sent Events. It has two main advantages. The biggest one being that the protocol allows for bidirectional communication. Messages can be received in real-time but also sent through the same channel. WebSockets network packets have less overhead than SSE since - once the handshake is performed - data is directly sent over TCP (thus the HTTP header is not needed anymore). This also means that binary data can be sent as well whereas SSE only handles utf-8 encoded text.

Server-Sent Events are better than WebSockets

The minor advantages that WebSockets have over SSE should not be a deal-breaker in most situations. Removing the HTTP header overhead is an optimization that will only make sense in some very specific contexts (if thousands of updates are sent per second for example). Also if binary data streaming is absolutely needed it can be base64 encoded and sent as text. Finally the main feature WebSockets have that SSE lack is completely redundant in the web context. HTTP requests are executed in real-time by definition since they are initiated by the client. Prior to SSE the real missing feature was receiving updates without querying the server not sending them.

From a practical web developer perspective WebSockets have one major drawback. Although this technology depends on HTTP it uses its own protocol whereas SSE only use HTTP. It means that SSE are way simpler to include in a typical REST API implementation than WebSockets. It is just an other HTTP route not an entirely distinct server. This is important because an other server means that some already implemented functionalities will have to be duplicated.

Typically authentication is a major issue in that context. If you are working on an API you probably already have a user authentication system, be it by cookies, JWT or something else. Therefore, if you need your real-time functions to be authenticated (target specific users for a notification, restrict resources access, etc…), you will have to implement an additional authentication system for the WebSockets server. This is especially problematic since WebSockets have no way to do this at the protocol level as opposed to HTTP. Authentication must be performed through the WebSockets connection itself. A common solution here is to create a standard authenticated HTTP route to generate a nonce that will be sent and consumed through the WebSockets connection in the first message. Not ideal.

The best use-case for WebSockets is a very throughput intensive unauthenticated web application that does not use HTTP to communicate with its back-end server. Which also implies to get rid of the HTTP REST semantics (GET/PUT/POST/DELETE requests) or re-implementing them. This not very common to say the least.

Conclusion

Server-Sent Events are simpler to use and implement than WebSockets. Since they are a part of the widely supported HTTP protocol it is easier to interact with other systems though this method (less firewall issues for example). HTTP already has a mechanism to implement server pushed updates. Why bother using an other technology when working on a web application ?