How do server sent event actually work?

Server-Sent Events (SSE) is an elegant mechanism in web development that allows servers to send real-time updates to clients. Unlike traditional HTTP communication that ends after a single request-response cycle, SSE extends this by creating a one-way channel for continuous data streaming from the server to the client.

What Makes SSE Special?

SSE takes advantage of the HTTP protocol to deliver a streaming response that appears infinite. This continuous response, broken into chunks, is parsed by the client into discrete events or messages. The brilliance lies in its simplicity and the re-use of existing HTTP infrastructure.

How SSE Works

1. Initial Request: The client initiates a connection with a special request to the server, indicating it expects event streams.
2. Streaming Response: The server sends data in chunks, using a text/event-stream content type. Each chunk starts with data: and ends with two newlines.
3. Client-Side Parsing: The client uses an EventSource object to interpret and handle these data chunks. This unidirectional communication model works seamlessly with HTTP servers, including basic setups, without the complexity of WebSockets.

Use Cases for SSE

• Real-Time Notifications: Deliver updates such as messages, stock prices, or server status without needing complex WebSocket setups.
• Event Feeds: Provide live updates for dashboards or logs.
• Compatibility: SSE is designed for the web, making it easy to integrate into browsers without additional libraries.

Advantages of SSE

• Real-Time Updates: Clients receive data immediately as events occur on the server.
• HTTP Compatibility: Works with standard HTTP/1.1 servers and requires no specialized protocols.
• Ease of Implementation: Built-in browser support through the EventSource object eliminates the need for external libraries.

Limitations and Considerations

• Connection Limits: Browsers limit the number of concurrent HTTP connections to a single domain (often six for HTTP/1.1), which can be problematic if multiple SSE streams are opened.
• Client-Dependent: The client must remain online to receive events.
• Fallbacks for Older Protocols: SSE struggles with HTTP/1.1 limitations, but HTTP/2 mitigates these with multiplexed streams.

Example Implementation

Here’s how SSE works in practice using Node.js and the Express framework:

Server Code:

const express = require('express');
const app = express();

app.get('/stream', (req, res) => {
    res.setHeader('Content-Type', 'text/event-stream');
    let counter = 0;

    const interval = setInterval(() => {
        res.write(`data: Message ${counter++}\n\n`);
    }, 1000);

    req.on('close', () => clearInterval(interval));
});

app.listen(8888, () => console.log('Server running on port 8888'));

Client Code:

const eventSource = new EventSource('http://localhost:8888/stream');

eventSource.onmessage = (event) => {
    console.log('Received:', event.data);
};

Output: The client will continuously log messages like:

Received: Message 0
Received: Message 1

The provided code demonstrates how to implement Server-Sent Events (SSE) using Node.js and Express. It sets up a simple web server that listens for GET requests at the /stream endpoint. When a client connects, the server sends a continuous stream of events using the text/event-stream content type, ensuring the client recognizes the data as a stream of events.

A setInterval function sends messages every second to the client by writing data in the SSE format, where each message is prefixed with data: and ends with two newline characters (\n\n). The server also listens for client disconnections using req.on('close') and clears the interval to stop sending messages, preventing unnecessary resource usage.

The server runs on port 8888, and clients can connect to it using the EventSource object to receive real-time updates continuously until the connection is closed. This approach is ideal for one-way real-time communication from the server to the client.

Challenges with SSE

• Server Load: Handling multiple long-lived connections can be taxing on the server.
• Offline Handling: If a client disconnects, managing missed messages can be tricky.
• Polling vs. Streaming: For lightweight clients, traditional polling might be a better fit.

Conclusion

While SSE excels in specific scenarios, it’s not a one-size-fits-all solution. For bidirectional communication, WebSockets might be preferable. As web technologies evolve, protocols like HTTP/2 further enhance SSE by overcoming many of its limitations.

With its elegance and simplicity, SSE is a powerful tool for building dynamic, real-time web applications. Whether for notifications, logs, or live data feeds, it remains an accessible and effective choice.