Your Web News in One Place

Help Webnuz

Referal links:

Sign up for GreenGeeks web hosting
April 29, 2022 08:25 am GMT

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.

Its 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 doesnt 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, its 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.

Lets try to explain both approaches and their characteristics.

Websocket

Its 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 its 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 dont 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 doesnt automatically recover them, you need to implement a reconnection system by yourself.
  • Browsers older than 2011 dont support WebSocket connections.
  • Some enterprise firewalls with packet inspection have trouble dealing with WebSocket.

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

Its 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 its been a while since its 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

  • Its limited to UTF-8 and does not support binary data.
  • Its subject to limitation with regards 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).
  • Its mono-directional
  • It doesnt 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, its 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.


Original Link: https://dev.to/minompi/websocket-vs-server-sent-events-2b77

Share this article:    Share on Facebook
View Full Article

Dev To

An online community for sharing and discovering great ideas, having debates, and making friends

More About this Source Visit Dev To