What is Server Side Event(SSE)?

Server-Sent Events (SSE) is a technology that allows a server to push real-time updates to a web page over a single, long-lived HTTP connection.

While standard HTTP follows a “request-response” cycle (you ask, the server answers, then hangs up), SSE keeps the “phone line” open so the server can shout out updates whenever they happen.

Using SSE in your browser is remarkably simple because it is a built-in Web API.

1. How It Works (The “Radio Broadcast” Model)

Think of SSE like a radio station.

1. Tuning In: The client (browser) “tunes in” to a specific URL on the server using a JavaScript object called EventSource.
2. Staying Connected: The server responds, but it doesn’t close the connection. It keeps it open.
3. Streaming: Whenever the server has new info (a stock price change, a new chat message, a score update), it sends a “chunk” of data down that open pipe.
4. Automatic Reconnect: If the connection drops (like driving through a tunnel), the browser automatically tries to reconnect to the “station.”

2. The Data Format (The “Wire” Protocol)

The server must send the data in a very specific plain-text format. It must use the header Content-Type: text/event-stream.

A typical message from the server looks like this:

Plaintext

event: user-login
data: {"username": "Alice", "time": "11:36"}

data: This is a simple message without a custom event name.

• **event:** (Optional) Gives the message a specific name (like a "channel").
• **data:** The actual content. If the message is long, you can use multiple data: lines.
• **id:** (Optional) A unique ID for the message. If the connection breaks, the browser sends the "Last-Event-ID" to the server so it can resume exactly where it left off.
• **retry:** (Optional) Tells the browser how many milliseconds to wait before trying to reconnect if the line drops.

What is Difference between websockets and SSE?

1. Communication flow — SSE is for server to client data communication where websockets is bi-directional used to real time communcation.
2. Protocol — SSE used HTTP standard protocol where websockets used specific ws:// protocol.
3. Reconnection- SSE automatic reconnect whereas websockets need manual reconnection.
4. Firewalls Passage — SSE can passe the firewalls whereas websocket sometime can be blocked

How SSE Work with HTTP/1.1 and HTTP/2?

1. The HTTP/1.1 Way: Separate Pipes

In HTTP/1.1, a TCP connection can only handle one request/response at a time. Since SSE is a “hanging” request that never officially ends, it “clogs” that connection indefinitely.

• If you create 6 EventSource objects in your JS code, the browser opens 6 separate TCP connections.
• Because browsers have a hard limit of 6 connections per domain, your 7th request (whether it’s another SSE or just a simple image) will be blocked until one of the others is closed.

2. The HTTP/2 Way: One Pipe, Many Lanes

HTTP/2 introduced a feature called Multiplexing. Instead of opening new TCP connections, it creates “Streams” inside a single, existing TCP connection.

• Can you write 6 EventSources in JS? Yes! You can actually write 10, 20, or even 100.
• How it works: All those EventSource objects will travel through the same single TCP connection. They are assigned "Stream IDs," allowing the browser to keep the data for EventSource_A separate from EventSource_B even though they are moving through the same "pipe."

Note: While HTTP/2 theoretically allows hundreds of streams, the server usually sets a limit (often SETTINGS_MAX_CONCURRENT_STREAMS = 100). This is much higher than the old limit of 6.

Browser Fail-safe: If for some reason the connection drops back to HTTP/1.1 (due to an old proxy, a corporate firewall, or a server misconfiguration), your app will suddenly break if it relies on more than 6 streams.