Server-Sent Events: lightweight alternative for a few websockets use cases. SSE vs. WebSockets!
Table of Contents
Probably a lot of us know what is websocket or at least faced a need to ensure bidirectional, reactive communication between frontend and backend. We can distinguish many kinds of applications which need such dynamic types of communication, because without it they are not so useful. For example, imagine a chat app such as WhatsApp or FB’s Messenger without dynamic, fluent background messages refreshing. In such cases you have to refresh the page manually to allow the frontend to fetch new records from the backend. It will be a really painful thing for the user’s experience. I don’t know how old you are but the first chat applications looked almost like this.
First solution: cyclic pooling
Provisional solution for the problem of dynamic refreshes can be cyclic pooling. So we can simply define an interval, for example two seconds, and then fetch new records every two seconds and simply add them to existing ones. This solution is not so good, because we have to make a network request every single time when interval function is invoked. Imagine a scenario when a user has low internet connection speed and needs to wait 3 seconds for a response. Before the first call ends we do another one. Of course we can provide some concurrency or increase interval threshold and wait for responses, but is it really a dynamic solution? I don’t think so.
Bidirectional communication with WebSockets
Better idea to solve the problem is to provide bidirectional communication by using WebSockets. WebSocket is TCP protocol allowing to open connections between frontend and backend and dynamically exchange information between them. WebSockets communication starts as a normal HTTP connection and it is enhanced to WebSocket connection by WS handshake. In this solution we can push new events, messages and basically inform the front side of our application fully dynamically. Another great thing is that the frontend can also send stuff to the backend through WebSocket connection without opening new sessions.
We can use many libraries such as socket.io or pick SaaS solutions, for example Pusher to achieve this even more easily.
An alternative: Server-Sent Events (SSE)
Next option to (partially) solve our problem is to use a quite new solution called Server-Sent Events. It also provides the possibility to dynamically synchronize content with the backend but only in one direction. By using SSE we agree that we will only receive dynamic messages on the frontend side. There is no possibility to send messages via SSE from the client side.
You can think, so why should I use SSE if WebSocket provides more? Yes, that is true, but in many scenarios bidirectional dynamic communication is redundant and we open WebSocket for example just to receive notifications for a client. For such cases SSE fits better than WebSockets.
Implementation of Server-Sent Events technology requires the use of the EventSource class on the frontend side and continuously sending events on the backend side.
SSE vs. WebSockets – Conclusion
We came a long way from applications which had to programmatically implement pseudo dynamic background refreshes to WebSockets uses. Now we also have a more lightweight possibility to ensure dynamic communication between frontend and backend in the form of one direction events communication by using Server-Sent Events technology. Consider using SSE instead of WebSockets if you have to provide one direction dynamic communication features, such as notifications systems.
You may like to read:
Backend Developer vs Frontend – differences and responsibilities
Backend developers: How to start down the career path
The Skills You Need to Be a Back-End Developer
QA in software development – everything you should know
10 frontend developer skills the market wants right now