WebSocket vs Server-Sent events
Usually, I have heard more times the term WebSocket than server-sent events.
The reason could be that WebSocket is used more, but not always is the ideal approach.
Sometimes Server-sent events approach is better to solve problems and create good applications.
It’s very important to understand differences, limits, and ideal cases for both to solve your problem with the right solution.
Sometimes we have a cognitive bias that doesn’t allow us to take the right decision.
Cognitive bias is a systematic error in thinking that occurs when people are processing and interpreting information in the world around them and affects the decisions and judgments that they make.
(Image from https://uxdesign.cc/how-to-improve-experience-design-by-managing-cognitive-biases-d7b360d35b0a)
So, for example, if we have solved a problem using WebSocket, next time with a similar problem we could think that, again, it’s the right approach without considering the big picture, all information about the problem to solve.
For that reason, understanding deeply bot approaches can help us to reduce the cognitive bias and make the best decision.
Let’s try to explain both approaches and their characteristics.
Websocket
It’s a computer communications protocol, that provides full-duplex communication channels over a single TCP connection (Wikipedia). The protocol was standardized in 2011.
The WebSocket approach is used in many contexts and projects because has many benefits and pros in its favor.
Bidirectional communication
The client and server can both send data to the other part.
The client creates a TCP connection to the server and keeps it open as long as needed.
Both server and client can close the connection easily whenever they want.
To exchange data there is a handshake process that verifies the communication, and if it’s all ok, they can exchange data using the custom WebSocket protocol.
(Image from: https://www.onlyfullstack.com/polling-vs-server-sent-events-vs-websocket/)
Advantages
- Bidirectional communication in real-time, connections can both send and receive data from the browser(example: chat).
- Generally don’t use XmlHttpRequest and headers are not sent every time, so it reduces the expensive data loads being sent to the server.
- Can transmit both binary data and UTF-8 format.
Limits
- When connections are terminated, WebSocket doesn’t automatically recover them, you need to implement a reconnection system by yourself.
- Browsers older than 2011 don’t support WebSocket connections.
- Some enterprise firewalls with packet inspection have trouble dealing with WebSocket.
- It cannot be placed behind container-based authentication methods with header-based security, it has to be query parameters (or hopefully, a token-based authentication where the token is established outside the WebSocket path).
Ideal cases
- Chat: both client and server exchange data to send and receive messages
- Multiplayer games
- Collaborative editing/coding
- Social feeds
- Sport updates
- … a lot more …
Server-Sent Events
It’s a server push technology enabling a client to receive automatic updates from a server via an HTTP connection.
It was born on September 1, 2006, so it’s been a while since it’s available.
It provides a memory-efficient implementation of XHR streaming.
Unlike a raw XHR connection, which buffers the full received response until the connection is dropped, an SSE connection can discard processed messages without accumulating all of them in memory.
Monodirectional communication
The client sends a request to subscribe to a specific channel and the server will send event/data into that request, so only the server can send data and the client receive automatically those events in the same HTTP connection.
(Image from: https://www.onlyfullstack.com/polling-vs-server-sent-events-vs-websocket/)
Advantages
- Transported over simple HTTP instead of a custom protocol
- Simpler protocol
- Built-in support for re-connection and event-id
- No troubles with corporate firewalls doing packet inspection
Limits
- It’s limited to UTF-8 and does not support binary data.
- When not used over HTTP/2, Server-Sent events approach is subject to limitations with regard to the maximum number of open connections. This can be especially painful when opening various tabs as the limit is per browser and set to a very low number (6).
- It’s mono-directional
- It doesn’t have native browser support. However, there are available workaround with poly-fill (replicate an API) in Javascript that simulates the SSE functionality to solve this issue. All modern browsers support server-sent events: Firefox 6+, Google Chrome 6+, Opera 11.5+, Safari 5+, Microsoft Edge 79+.
Ideal cases
- Stock client updates: the client receives updates from the server when a stock changes its value
- Twitter feed updates: the client receives a new tweet every time one is sent
- push notifications
Conclusion
In conclusion, both approaches are valid and can be used to build specific software.
Websocket is more used and can be used also to develop an application that can use Server-sent events.
Server-sent Events have fewer ideal cases but for them, it’s very useful with less configuration and less time to create the updating system.
I have used both of them and no one is better than another, it depends on the specific context and what you need at that moment.
Knowing WebSocket and Server-sent events can help you in deciding which approach is better for every application.
