Server Side Events(SSE) are underrated

Today, I was years old when I found out about server-sent events.  After researching more about it, I thought, “Why not share this underrated gem with the public?”. 

This blog is written by Akshat Virmani at KushoAI. We're building the fastest way to test your APIs. It's completely free and you can sign up here.

Here is what I found:

What Are Server-Sent Events (SSE)?

Server-Sent Events is a web technology that allows servers to send real-time updates to clients over a single HTTP connection. SSE is built on HTTP and utilises the EventSource API in the browser to establish a one-way communication channel from the server to the client.

In SSE, the server can push updates to the client, but the client cannot send messages back to the same channel. This is not considered a drawback in many scenarios where one-way communication exists, Unlike WebSockets, which support full-duplex communication.

The Advantages of SSE

These are some of the advantages of SEE, and I will compare it to WebSockets.

1. Simplicity and Ease of Implementation

Setting up an SSE connection requires minimal effort compared to WebSockets. It uses plain HTTP, which makes it easy to integrate with existing infrastructure.

2. Lightweight Protocol

SSE is lightweight, making it ideal for scenarios where low-latency, one-way communication is sufficient.

3. Automatic Reconnection

Developers don’t need to write additional code to handle reconnection logic in case of network interruption, making SSE a more resilient choice for real-time applications as the EventSource API includes built-in support for automatic reconnection. 

4. Native Support in Browsers

Unlike WebSockets, SSE supports modern web browsers, including Chrome, Firefox, and Edge, and does not require additional libraries for older environments. 

5. Efficient for Broadcasting Updates

When the server needs to send the same update to multiple clients, SSE excels. It’s efficient for scenarios like live news feeds, stock price updates, or real-time dashboards. The simplicity of broadcasting makes SSE a go-to choice for many such use cases.

Limitations of SSE

While SSE is a powerful tool, it has limitations:

1. Unidirectional Communication: SSE is only server-to-client communication, which might not be suitable for applications that require two-way or bidirectional data flow.
2. Browser Support: While modern browsers support SSE, Internet Explorer does not. However, polyfills are available to address this limitation.
3. Lack of Binary Data Support: SSE only supports text-based data. Applications requiring binary data transfer should consider WebSockets or other alternatives.

Code Example

Let's take a quick example of SSE. 

Receiving events from the server

The code checks for browser support for Server-Sent Events (SSE) using “EventSource” and connects to the server at “ServerUpdate.php” to receive real-time updates. Each server-sent message triggers the “onmessage event”, appending the message to the div with the ID “output”. If SSE is unsupported, it logs an error in the console.

Sending events from the server

The server tells the browser that it sends live updates by setting a special type and ensuring updates aren't stored. It sends messages starting with “data” so the browser knows it's new information. The flush() command ensures the update reaches the browser immediately.

How do I check if my browser supports SSE using HTML?

The code mentioned below can detect if your browser supports SSE.

When to Choose SSE

SSE is an excellent choice for applications where:

• The server needs to push real-time updates to the client.
• Unidirectional communication is present.
• Simplicity and ease of integration are priorities.
• The application primarily uses text-based data.

Examples include live sports scoreboards, weather updates, event tracking systems, real-time monitoring dashboards, applications like email clients' team communication tools, social media platforms, etc., to deliver real-time notifications and, most importantly, nowadays used to generate outputs in ChatGPT or similar conversational AI tools.

Common Issues When Setting Up SSE on the Server Side:

1. Improper Content-Type Header: Forgetting to set the “Content-Type” to “text/event-stream” can cause the client to not recognise the response as a stream.
2. No Periodic Keep-Alive Messages: Some servers or proxies close idle connections. Sending periodic comments (: keep-alive\n\n) helps keep the connection open.
3. Buffering Issues: Without “flush()” or similar commands, data may remain in the server's output buffer instead of being sent to the client immediately.

Conclusion: 

We have reached the end of the blog. In this blog, we covered everything you need to know about SSE. Why not give SSE a try if you haven't already

This blog is written by Akshat Virmani at KushoAI. We're building the fastest way to test your APIs. It's completely free and you can sign up here.