Enjoy!<\/p>\n\n\n\n
A brief introduction to SSE<\/strong><\/h2>\n\n\n\nServer Side Events is a web technology that enables a unidirectional, real-time communication channel between a web server and a client, typically a web browser. In a nutshell \u2013 you create a long-lived HTTP connection between a server and a browser, and then the server can send asynchronous messages to the browser without user involvement. This is useful for applications like stock market updates, social media feeds, and collaborative tools where real-time updates are crucial.<\/p>\n\n\n\n
Why should I use SSE?<\/strong><\/h2>\n\n\n\nSSE has gained popularity for several compelling reasons:<\/p>\n\n\n\n
\n- Efficiency<\/strong> \u2013 SSE operates over a single HTTP connection without requiring multiple requests (as in short or long polling). This efficiency reduces server load and network overhead.<\/li>\n\n\n\n
- Simplicity <\/strong>\u2013 implementing SSE on both the server and client sides is straightforward, as it leverages familiar web technologies like HTML, JavaScript, and standard HTTP protocols. There is no need for third-party libraries or complex configurations! All major web browsers, including Chrome, Firefox, Safari, Edge, and Opera, support SSE. IE is the only major browser that doesn\u2019t support SSE.<\/li>\n\n\n\n
- Real-Time Updates <\/strong>\u2013 SSE enables real-time updates from the server to the client, allowing instant notifications of events or changes in state.<\/li>\n\n\n\n
- Fallback Mechanism<\/strong> \u2013 SSE gracefully handles scenarios where a client’s browser lacks support for SSE. It automatically falls back to other techniques like long polling, ensuring that your application remains functional across various environments.<\/li>\n<\/ul>\n\n\n\n
Advantages and limitations of SSE<\/strong><\/h2>\n\n\n\nAmong the advantages of the solution are:<\/a><\/strong><\/p>\n\n\n\n\n- Ease of Implementation <\/strong>\u2013 <\/strong>Implementing SSE Events for the first time took me around 3-4 hours. It doesn’t require complex libraries or additional technologies, simplifying the creation of streaming applications.<\/li>\n\n\n\n
- Low Network Overhead <\/strong>\u2013 <\/strong>SSE relies on a single, persistent connection to the server, enabling real-time data transmission with a minimal network overhead. You don’t need to open and close multiple connections, positively impacting application performance.<\/li>\n<\/ul>\n\n\n\n
\n- No need to constantly request the server <\/strong>\u2013 <\/strong>once a connection is established as a server-client, you don\u2019t need to constantly request the server if some business status has been changed. When the server changes its status, it can directly send you the event with details of what has changed.<\/li>\n\n\n\n
- Error Handling <\/strong>\u2013 <\/strong>backend SSE implementation and frontend EventSource provide an API that helps us handle unforeseen situations easily.<\/strong><\/li>\n<\/ul>\n\n\n\n
Disadvantages of the solution include:<\/p>\n\n\n\n
\n- Limit of maximum open connections <\/strong>\u2013 <\/strong>when not used over HTTP\/2, SSE suffers from a limitation to the maximum number of open connections, which can be especially painful when opening multiple tabs, as the limit is per browser and is set to a very low number (6).
When used over HTTP\/2 protocol, the maximum number of simultaneous HTTP streams depends on the server and client configuration but, by default, is set to 100.<\/li>\n\n\n\n- Unidirectional Communication <\/strong>\u2013 <\/strong>SSE technology enables communication only from the server to the client. It creates limitations, so it may not be the best choice for more complex, interactive applications where bidirectional communication or frequent client-server interactions are needed. On the other hand, unidirectional communication is safer, as the stream of events goes from the server to the user.<\/li>\n<\/ul>\n\n\n\n
Implementing the Spring Boot Server<\/strong><\/h2>\n\n\n\nTo present the capabilities of Server Side Events technology, I\u2019ve created a simple app that monitors business processes. <\/p>\n\n\n\n
The business logic of the backend system is simple. We have defined 3 three paths:<\/p>\n\n\n\n
\n- Happy path,<\/li>\n\n\n\n
- Warning path,<\/li>\n\n\n\n
- Error path.<\/li>\n<\/ul>\n\n\n\n
Whenever a monitoring request is made, the system randomly picks and follows one of the paths. Simulates a sample business process that sends status events whenever its state changes. <\/p>\n\n\n\n
The working system is below:<\/p>\n\n\n\n![\"Business](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/12\/image1.gif\")
Fig. 1 Business Pocess Monitoring<\/figcaption><\/figure>\n\n\n\nApplication structure:<\/p>\n\n\n\n![\"Application](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/12\/Obraz2-1.png\")
<\/a>Fig. 2 Application structure<\/figcaption><\/figure>\n\n\n\nController handling SSE<\/strong><\/h3>\n\n\n\nPlain RestController exposes SseEmitter on GET request. SseEmitter is a class of Spring MVC. It will be exposed over HTTP with a content type as text\/event stream. Thus, a browser can request and handle it as an EventSource.<\/p>\n\n\n\n
When a request reaches this method, the SSE Event Processor service creates a new SSEEmitter and starts an asynchronous monitoring process.<\/p>\n\n\n\n![\"code\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/12\/Obraz3-1.png\")
<\/a><\/figure>\n\n\n\nProcessor handling Server Side Events<\/strong><\/h3>\n\n\n\n![\"code\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/12\/Obraz4-1.png\")
<\/a><\/figure>\n\n\n\nThis service keeps all created emitters. During the creation process, a new SseEmitter object is created and then stored in a Map.<\/p>\n\n\n\n![\"code\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/12\/Obraz5-1.png\")
<\/a><\/figure>\n\n\n\nDuring sending an event, the SseEmitter object is retrieved from the map, and the send method is invoked with an event message. Object SseEventModel is a custom model created for this application.
If the client aborts the connection and the server wants to send a new event \u2013 ClientAbortException is called.<\/p>\n\n\n\n![\"code\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/12\/Obraz6-1.png\")
<\/a><\/figure>\n\n\n\nThe process ends when the termination event is sent, and the connection is completed.<\/p>\n\n\n\n
For that, I\u2019ve used a message with the flag finished<\/em> set to true \u2013 the client then can handle the connection appropriately.<\/p>\n\n\n\nBusiness Process Monitoring<\/strong><\/h3>\n\n\n\nThis service simulates an ongoing process that is monitored, and the events are sent.<\/p>\n\n\n\n
We have defined 3 constant paths:<\/p>\n\n\n\n
\n- Happy path,<\/li>\n\n\n\n
- No data,<\/li>\n\n\n\n
- Error Path.<\/li>\n<\/ul>\n\n\n\n
![\"code\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/12\/Obraz7-1.png\")
<\/a><\/figure>\n\n\n\nSimulation of the monitoring process is just picking randomly a path defined above and waiting after every notification.<\/p>\n\n\n\n![\"code\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/12\/Obraz8-1.png\")
<\/a><\/figure>\n\n\n\nSending an event is done by calling SseEventProcessor.<\/p>\n\n\n\n![\"code\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/12\/Obraz9-1.png\")
<\/a><\/figure>\n\n\n\nImplementing the Angular Client<\/strong><\/h2>\n\n\n\nWe can obtain an EventSource exposed by the server by simply calling the constructor of the EventSource class. Every modern browser supports this class.<\/p>\n\n\n\n![\"Server-sent](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/12\/Przechwytywanie-1-1024x366.jpg\")
<\/a>Fig. 3 Server-sent events<\/figcaption><\/figure>\n\n\n\n![\"code\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/12\/Obraz11-1.png\")
<\/a><\/figure>\n\n\n\nWe can define three types of handlers for an event source:<\/p>\n\n\n\n
\n- onmessage <\/em><\/strong>\u2013 function will be invoked upon the message’s arrival,<\/li>\n\n\n\n
- onerror <\/em><\/strong>\u2013 will be invoked when the error occurs,<\/li>\n\n\n\n
- onopen <\/em><\/strong>\u2013 will be invoked when the connection will be opened.<\/li>\n<\/ul>\n\n\n\n
Let’s break down the piece of code responsible for receiving the message:<\/p>\n\n\n\n![\"code\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/12\/Obraz12.png\")
<\/a><\/figure>\n\n\n\nWhen the event comes, we extract its data, only text in JSON format. We\u2019re closing the connection when the finished event is sent. If not, we\u2019re using messageSubject$ to push the received message. <\/p>\n\n\n\n
MessageSubject$ is an Angular\u2019s Subject, which can then be subscribed to display elements on the screen. <\/p>\n\n\n\n
ProcessMonitoringService exposes 3 public methods:<\/p>\n\n\n\n
\n- startMonitoring,<\/li>\n\n\n\n
- getMessageObservable \u2013 responsible to return messageSubject$ as an observable,<\/li>\n\n\n\n
- stopMonitoring.<\/li>\n<\/ul>\n\n\n\n
![\"code\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/12\/Obraz13.png\")
<\/a><\/figure>\n\n\n\nI\u2019ve assumed that the connection will be open for different users. For demo purposes, I\u2019ve generated a random user ID to pass as a parameter in creating a Server Side Event Connection request. Then, we can subscribe to the messages in the component and display them to the user. <\/p>\n\n\n\n
The component handling the view simply keeps processes as an array, which is updated every time a message is received.<\/p>\n\n\n\n![\"code\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/12\/Obraz14.png\")
<\/a><\/figure>\n\n\n\nWe employ the NgZone service to automatically update the component view on the arrival of a message. Without this, we would have to rely on user interaction to display the message correctly. Full code for the frontend and the backend application is available on GitHub<\/a>. <\/p>\n\n\n\nUnder the hood<\/strong><\/h2>\n\n\n\nBut how does it work under the hood?<\/p>\n\n\n\n
At the beginning, the browser is opening the connection:<\/p>\n\n\n\n![\"The](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/12\/Przechwytywanie1-1024x606.jpg\")
<\/a>Fig. 4 The connection<\/figcaption><\/figure>\n\n\n\nThe diagram below illustrates the life cycle of an event source:<\/p>\n\n\n\n![\"The](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/12\/Obraz16.png\")
<\/a>Fig. 5 The life cycle of an event source<\/figcaption><\/figure>\n\n\n\nThe connection is kept open until the proper event completes the connection. <\/p>\n\n\n\n
In the browser, we\u2019re able to see incoming events:<\/p>\n\n\n\n![\"Incoming](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/12\/Przechwytywanie3-1024x209.jpg\")
<\/a>Fig. 6 Incoming events<\/figcaption><\/figure>\n\n\n\nWe see that the last message has a finished flag set to true. This way, in the code, we\u2019re able to handle closing connections on the client side more gracefully:<\/p>\n\n\n\n![\"code\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/12\/Obraz18.png\")
<\/a><\/figure>\n\n\n\nBut what happens if we lose the connection? Simulating that the server is down after successfully obtaining the connection, we can see that the browser, by default, automatically tries to reconnect to the source:<\/p>\n\n\n\n![\"Automatically](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/12\/Przechwytywanie4-1024x147.jpg\")
<\/a>Fig. 7 Automatically reconnection<\/figcaption><\/figure>\n\n\n\nDisclaimer \u2013 this situation happens if we don\u2019t handle closing the connection in case of failure.
In my example of process monitoring, I\u2019ve handled this case by closing the connection in case of failure:<\/p>\n\n\n\n![\"code\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/12\/Obraz20.png\")
<\/a><\/figure>\n\n\n\nNevertheless, the behavior of automatically reconnecting can be different among different types of browsers; thus, I recommend handling reconnecting with EventSource manually.<\/p>\n\n\n\n
Security with EventSource<\/strong><\/h2>\n\n\n\nEventSource mechanism enables us to provide a withCredentials flag into the constructor.<\/p>\n\n\n\n![\"code\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/12\/Obraz21.png\")
<\/a><\/figure>\n\n\n\nWhen withCredentials is true, the browser will include cookies and HTTP headers in SSE requests, such as the Authorization header. This enables user authentication and authorization on the server, similar to standard HTTP requests.<\/p>\n\n\n\n
Comparing SSE with other technologies<\/strong><\/h2>\n\n\n\nShort Polling<\/strong><\/h3>\n\n\n\nIt involves clients making frequent, regular requests to the server for updates. These requests are usually quick and lightweight, making Short Polling a simple solution. However, it can lead to higher network and server resource consumption, as clients consistently ask for updates, even when no new data is available. This constant “polling” can be inefficient and strain the client and server unnecessarily.<\/p>\n\n\n\n
\n- Protocol<\/strong>: HTTP,<\/li>\n\n\n\n
- Connection type<\/strong>: frequent queries for updates,<\/li>\n\n\n\n
- Performance<\/strong>: excessive network traffic because the client needs to ask the server for updates.<\/li>\n<\/ul>\n\n\n\n
Long Polling<\/strong><\/h3>\n\n\n\nLong Polling is a variation of the polling method designed to mitigate some inefficiencies associated with Short Polling. With Long Polling, clients request the server, and the server holds the request open until new data is available or a timeout occurs. The server responds to the client’s request once data becomes available or the timeout is reached. This approach reduces the constant back-and-forth polling of Short Polling, but it might not be as efficient as more modern solutions like WebSockets or SSE.<\/p>\n\n\n\n
\n- Protocol<\/strong>: HTTP,<\/strong><\/li>\n\n\n\n
- Connection type:<\/strong> persistent client-server connection, the server delays response,<\/li>\n\n\n\n
- Performance<\/strong>: high resource usage on the server as well as on the client side due to frequently opening new connections.<\/li>\n<\/ul>\n\n\n\n
WebSockets<\/strong><\/h3>\n\n\n\nWebSockets provide a more sophisticated and efficient means of real-time communication. They offer full-duplex, bidirectional communication, enabling both the client and server to send messages to each other at any time without the need for repeated requests. WebSockets are highly efficient, reducing network overhead and allowing for near-instant data transmission.<\/p>\n\n\n\n
\n- Protocol<\/strong>: WebSocket protocol,<\/li>\n\n\n\n
- Connection type:<\/strong> full-duplex connection,<\/li>\n\n\n\n
- Performance<\/strong>: highly efficient and fast without excessive delay or continuous server polling.<\/li>\n<\/ul>\n\n\n\n
Comparison of diagram:<\/p>\n\n\n\n![\"Comparision](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/12\/Przechwytywanie5.jpg\")
<\/a>Fig. 8 Comparision SSE with other technologies<\/figcaption><\/figure>\n\n\n\nBusiness scenarios where SSE can be used<\/strong><\/h2>\n\n\n\nThere’s a huge area where unidirectional communication between servers and clients can be used.
Here are some examples of how Server Side Events can be used.<\/p>\n\n\n\n
\n- Social Media Feeds \u2013 instantly deliver posts, comments, and notifications to users,<\/li>\n\n\n\n
- Sports Updates and Scores \u2013 live notifications, up-to-date scores,<\/li>\n\n\n\n
- Live updates for financial markets \u2013 providing real-time updates on stock prices and currency exchange rates,<\/li>\n\n\n\n
- monitor system processes and provide the user with the actual state of the process.<\/li>\n<\/ul>\n\n\n\n
Conclusion<\/strong><\/h2>\n\n\n\nAs you have seen, server-side events can be effectively used in vast business scenarios<\/strong>.<\/p>\n\n\n\nI hope this article has shown you how to use SSE technology and introduced you to this type of communication. I hope this helps you handle use cases in your system more effectively!<\/p>\n\n\n\n
Full code is available on GitHub<\/a>.<\/p>\n\n\n\nSources<\/strong><\/h2>\n\n\n\n
SSE has gained popularity for several compelling reasons:<\/p>\n\n\n\n
- \n
- Efficiency<\/strong> \u2013 SSE operates over a single HTTP connection without requiring multiple requests (as in short or long polling). This efficiency reduces server load and network overhead.<\/li>\n\n\n\n
- Simplicity <\/strong>\u2013 implementing SSE on both the server and client sides is straightforward, as it leverages familiar web technologies like HTML, JavaScript, and standard HTTP protocols. There is no need for third-party libraries or complex configurations! All major web browsers, including Chrome, Firefox, Safari, Edge, and Opera, support SSE. IE is the only major browser that doesn\u2019t support SSE.<\/li>\n\n\n\n
- Real-Time Updates <\/strong>\u2013 SSE enables real-time updates from the server to the client, allowing instant notifications of events or changes in state.<\/li>\n\n\n\n
- Fallback Mechanism<\/strong> \u2013 SSE gracefully handles scenarios where a client’s browser lacks support for SSE. It automatically falls back to other techniques like long polling, ensuring that your application remains functional across various environments.<\/li>\n<\/ul>\n\n\n\n
Advantages and limitations of SSE<\/strong><\/h2>\n\n\n\n
Among the advantages of the solution are:<\/a><\/strong><\/p>\n\n\n\n
- \n
- Ease of Implementation <\/strong>\u2013 <\/strong>Implementing SSE Events for the first time took me around 3-4 hours. It doesn’t require complex libraries or additional technologies, simplifying the creation of streaming applications.<\/li>\n\n\n\n
- Low Network Overhead <\/strong>\u2013 <\/strong>SSE relies on a single, persistent connection to the server, enabling real-time data transmission with a minimal network overhead. You don’t need to open and close multiple connections, positively impacting application performance.<\/li>\n<\/ul>\n\n\n\n
- \n
- No need to constantly request the server <\/strong>\u2013 <\/strong>once a connection is established as a server-client, you don\u2019t need to constantly request the server if some business status has been changed. When the server changes its status, it can directly send you the event with details of what has changed.<\/li>\n\n\n\n
- Error Handling <\/strong>\u2013 <\/strong>backend SSE implementation and frontend EventSource provide an API that helps us handle unforeseen situations easily.<\/strong><\/li>\n<\/ul>\n\n\n\n
Disadvantages of the solution include:<\/p>\n\n\n\n
- \n
- Limit of maximum open connections <\/strong>\u2013 <\/strong>when not used over HTTP\/2, SSE suffers from a limitation to the maximum number of open connections, which can be especially painful when opening multiple tabs, as the limit is per browser and is set to a very low number (6).
When used over HTTP\/2 protocol, the maximum number of simultaneous HTTP streams depends on the server and client configuration but, by default, is set to 100.<\/li>\n\n\n\n- Unidirectional Communication <\/strong>\u2013 <\/strong>SSE technology enables communication only from the server to the client. It creates limitations, so it may not be the best choice for more complex, interactive applications where bidirectional communication or frequent client-server interactions are needed. On the other hand, unidirectional communication is safer, as the stream of events goes from the server to the user.<\/li>\n<\/ul>\n\n\n\n
Implementing the Spring Boot Server<\/strong><\/h2>\n\n\n\n
To present the capabilities of Server Side Events technology, I\u2019ve created a simple app that monitors business processes. <\/p>\n\n\n\n
The business logic of the backend system is simple. We have defined 3 three paths:<\/p>\n\n\n\n
- \n
- Happy path,<\/li>\n\n\n\n
- Warning path,<\/li>\n\n\n\n
- Error path.<\/li>\n<\/ul>\n\n\n\n
Whenever a monitoring request is made, the system randomly picks and follows one of the paths. Simulates a sample business process that sends status events whenever its state changes. <\/p>\n\n\n\n
The working system is below:<\/p>\n\n\n\n
Fig. 1 Business Pocess Monitoring<\/figcaption><\/figure>\n\n\n\n Application structure:<\/p>\n\n\n\n
<\/a>Fig. 2 Application structure<\/figcaption><\/figure>\n\n\n\n Controller handling SSE<\/strong><\/h3>\n\n\n\n
Plain RestController exposes SseEmitter on GET request. SseEmitter is a class of Spring MVC. It will be exposed over HTTP with a content type as text\/event stream. Thus, a browser can request and handle it as an EventSource.<\/p>\n\n\n\n
When a request reaches this method, the SSE Event Processor service creates a new SSEEmitter and starts an asynchronous monitoring process.<\/p>\n\n\n\n
<\/a><\/figure>\n\n\n\nProcessor handling Server Side Events<\/strong><\/h3>\n\n\n\n
<\/a><\/figure>\n\n\n\nThis service keeps all created emitters. During the creation process, a new SseEmitter object is created and then stored in a Map.<\/p>\n\n\n\n
<\/a><\/figure>\n\n\n\nDuring sending an event, the SseEmitter object is retrieved from the map, and the send method is invoked with an event message. Object SseEventModel is a custom model created for this application.
If the client aborts the connection and the server wants to send a new event \u2013 ClientAbortException is called.<\/p>\n\n\n\n<\/a><\/figure>\n\n\n\nThe process ends when the termination event is sent, and the connection is completed.<\/p>\n\n\n\n
For that, I\u2019ve used a message with the flag finished<\/em> set to true \u2013 the client then can handle the connection appropriately.<\/p>\n\n\n\n
Business Process Monitoring<\/strong><\/h3>\n\n\n\n
This service simulates an ongoing process that is monitored, and the events are sent.<\/p>\n\n\n\n
We have defined 3 constant paths:<\/p>\n\n\n\n
- \n
- Happy path,<\/li>\n\n\n\n
- No data,<\/li>\n\n\n\n
- Error Path.<\/li>\n<\/ul>\n\n\n\n<\/a><\/figure>\n\n\n\n
Simulation of the monitoring process is just picking randomly a path defined above and waiting after every notification.<\/p>\n\n\n\n
<\/a><\/figure>\n\n\n\nSending an event is done by calling SseEventProcessor.<\/p>\n\n\n\n
<\/a><\/figure>\n\n\n\nImplementing the Angular Client<\/strong><\/h2>\n\n\n\n
We can obtain an EventSource exposed by the server by simply calling the constructor of the EventSource class. Every modern browser supports this class.<\/p>\n\n\n\n
<\/a>Fig. 3 Server-sent events<\/figcaption><\/figure>\n\n\n\n <\/a><\/figure>\n\n\n\nWe can define three types of handlers for an event source:<\/p>\n\n\n\n
- \n
- onmessage <\/em><\/strong>\u2013 function will be invoked upon the message’s arrival,<\/li>\n\n\n\n
- onerror <\/em><\/strong>\u2013 will be invoked when the error occurs,<\/li>\n\n\n\n
- onopen <\/em><\/strong>\u2013 will be invoked when the connection will be opened.<\/li>\n<\/ul>\n\n\n\n
Let’s break down the piece of code responsible for receiving the message:<\/p>\n\n\n\n
<\/a><\/figure>\n\n\n\nWhen the event comes, we extract its data, only text in JSON format. We\u2019re closing the connection when the finished event is sent. If not, we\u2019re using messageSubject$ to push the received message. <\/p>\n\n\n\n
MessageSubject$ is an Angular\u2019s Subject, which can then be subscribed to display elements on the screen. <\/p>\n\n\n\n
ProcessMonitoringService exposes 3 public methods:<\/p>\n\n\n\n
- \n
- startMonitoring,<\/li>\n\n\n\n
- getMessageObservable \u2013 responsible to return messageSubject$ as an observable,<\/li>\n\n\n\n
- stopMonitoring.<\/li>\n<\/ul>\n\n\n\n<\/a><\/figure>\n\n\n\n
I\u2019ve assumed that the connection will be open for different users. For demo purposes, I\u2019ve generated a random user ID to pass as a parameter in creating a Server Side Event Connection request. Then, we can subscribe to the messages in the component and display them to the user. <\/p>\n\n\n\n
The component handling the view simply keeps processes as an array, which is updated every time a message is received.<\/p>\n\n\n\n
<\/a><\/figure>\n\n\n\nWe employ the NgZone service to automatically update the component view on the arrival of a message. Without this, we would have to rely on user interaction to display the message correctly. Full code for the frontend and the backend application is available on GitHub<\/a>. <\/p>\n\n\n\n
Under the hood<\/strong><\/h2>\n\n\n\n
But how does it work under the hood?<\/p>\n\n\n\n
At the beginning, the browser is opening the connection:<\/p>\n\n\n\n
<\/a>Fig. 4 The connection<\/figcaption><\/figure>\n\n\n\n The diagram below illustrates the life cycle of an event source:<\/p>\n\n\n\n
<\/a>Fig. 5 The life cycle of an event source<\/figcaption><\/figure>\n\n\n\n The connection is kept open until the proper event completes the connection. <\/p>\n\n\n\n
In the browser, we\u2019re able to see incoming events:<\/p>\n\n\n\n
<\/a>Fig. 6 Incoming events<\/figcaption><\/figure>\n\n\n\n We see that the last message has a finished flag set to true. This way, in the code, we\u2019re able to handle closing connections on the client side more gracefully:<\/p>\n\n\n\n
<\/a><\/figure>\n\n\n\nBut what happens if we lose the connection? Simulating that the server is down after successfully obtaining the connection, we can see that the browser, by default, automatically tries to reconnect to the source:<\/p>\n\n\n\n
<\/a>Fig. 7 Automatically reconnection<\/figcaption><\/figure>\n\n\n\n Disclaimer \u2013 this situation happens if we don\u2019t handle closing the connection in case of failure.
In my example of process monitoring, I\u2019ve handled this case by closing the connection in case of failure:<\/p>\n\n\n\n<\/a><\/figure>\n\n\n\nNevertheless, the behavior of automatically reconnecting can be different among different types of browsers; thus, I recommend handling reconnecting with EventSource manually.<\/p>\n\n\n\n
Security with EventSource<\/strong><\/h2>\n\n\n\n
EventSource mechanism enables us to provide a withCredentials flag into the constructor.<\/p>\n\n\n\n
<\/a><\/figure>\n\n\n\nWhen withCredentials is true, the browser will include cookies and HTTP headers in SSE requests, such as the Authorization header. This enables user authentication and authorization on the server, similar to standard HTTP requests.<\/p>\n\n\n\n
Comparing SSE with other technologies<\/strong><\/h2>\n\n\n\n
Short Polling<\/strong><\/h3>\n\n\n\n
It involves clients making frequent, regular requests to the server for updates. These requests are usually quick and lightweight, making Short Polling a simple solution. However, it can lead to higher network and server resource consumption, as clients consistently ask for updates, even when no new data is available. This constant “polling” can be inefficient and strain the client and server unnecessarily.<\/p>\n\n\n\n
- \n
- Protocol<\/strong>: HTTP,<\/li>\n\n\n\n
- Connection type<\/strong>: frequent queries for updates,<\/li>\n\n\n\n
- Performance<\/strong>: excessive network traffic because the client needs to ask the server for updates.<\/li>\n<\/ul>\n\n\n\n
Long Polling<\/strong><\/h3>\n\n\n\n
Long Polling is a variation of the polling method designed to mitigate some inefficiencies associated with Short Polling. With Long Polling, clients request the server, and the server holds the request open until new data is available or a timeout occurs. The server responds to the client’s request once data becomes available or the timeout is reached. This approach reduces the constant back-and-forth polling of Short Polling, but it might not be as efficient as more modern solutions like WebSockets or SSE.<\/p>\n\n\n\n
- \n
- Protocol<\/strong>: HTTP,<\/strong><\/li>\n\n\n\n
- Connection type:<\/strong> persistent client-server connection, the server delays response,<\/li>\n\n\n\n
- Performance<\/strong>: high resource usage on the server as well as on the client side due to frequently opening new connections.<\/li>\n<\/ul>\n\n\n\n
WebSockets<\/strong><\/h3>\n\n\n\n
WebSockets provide a more sophisticated and efficient means of real-time communication. They offer full-duplex, bidirectional communication, enabling both the client and server to send messages to each other at any time without the need for repeated requests. WebSockets are highly efficient, reducing network overhead and allowing for near-instant data transmission.<\/p>\n\n\n\n
- \n
- Protocol<\/strong>: WebSocket protocol,<\/li>\n\n\n\n
- Connection type:<\/strong> full-duplex connection,<\/li>\n\n\n\n
- Performance<\/strong>: highly efficient and fast without excessive delay or continuous server polling.<\/li>\n<\/ul>\n\n\n\n
Comparison of diagram:<\/p>\n\n\n\n
<\/a>Fig. 8 Comparision SSE with other technologies<\/figcaption><\/figure>\n\n\n\n Business scenarios where SSE can be used<\/strong><\/h2>\n\n\n\n
There’s a huge area where unidirectional communication between servers and clients can be used.
Here are some examples of how Server Side Events can be used.<\/p>\n\n\n\n- \n
- Social Media Feeds \u2013 instantly deliver posts, comments, and notifications to users,<\/li>\n\n\n\n
- Sports Updates and Scores \u2013 live notifications, up-to-date scores,<\/li>\n\n\n\n
- Live updates for financial markets \u2013 providing real-time updates on stock prices and currency exchange rates,<\/li>\n\n\n\n
- monitor system processes and provide the user with the actual state of the process.<\/li>\n<\/ul>\n\n\n\n
Conclusion<\/strong><\/h2>\n\n\n\n
As you have seen, server-side events can be effectively used in vast business scenarios<\/strong>.<\/p>\n\n\n\n
I hope this article has shown you how to use SSE technology and introduced you to this type of communication. I hope this helps you handle use cases in your system more effectively!<\/p>\n\n\n\n
Full code is available on GitHub<\/a>.<\/p>\n\n\n\n
Sources<\/strong><\/h2>\n\n\n\n
- Connection type:<\/strong> full-duplex connection,<\/li>\n\n\n\n
- Connection type:<\/strong> persistent client-server connection, the server delays response,<\/li>\n\n\n\n
- Connection type<\/strong>: frequent queries for updates,<\/li>\n\n\n\n
- Protocol<\/strong>: HTTP,<\/li>\n\n\n\n
- onerror <\/em><\/strong>\u2013 will be invoked when the error occurs,<\/li>\n\n\n\n
- onmessage <\/em><\/strong>\u2013 function will be invoked upon the message’s arrival,<\/li>\n\n\n\n
- Unidirectional Communication <\/strong>\u2013 <\/strong>SSE technology enables communication only from the server to the client. It creates limitations, so it may not be the best choice for more complex, interactive applications where bidirectional communication or frequent client-server interactions are needed. On the other hand, unidirectional communication is safer, as the stream of events goes from the server to the user.<\/li>\n<\/ul>\n\n\n\n
- Error Handling <\/strong>\u2013 <\/strong>backend SSE implementation and frontend EventSource provide an API that helps us handle unforeseen situations easily.<\/strong><\/li>\n<\/ul>\n\n\n\n
- Low Network Overhead <\/strong>\u2013 <\/strong>SSE relies on a single, persistent connection to the server, enabling real-time data transmission with a minimal network overhead. You don’t need to open and close multiple connections, positively impacting application performance.<\/li>\n<\/ul>\n\n\n\n
- Simplicity <\/strong>\u2013 implementing SSE on both the server and client sides is straightforward, as it leverages familiar web technologies like HTML, JavaScript, and standard HTTP protocols. There is no need for third-party libraries or complex configurations! All major web browsers, including Chrome, Firefox, Safari, Edge, and Opera, support SSE. IE is the only major browser that doesn\u2019t support SSE.<\/li>\n\n\n\n