Server-Sent Events (SSE): One-Way Data Push from Server

Why it exists

Web applications often need to display data that updates in real-time, like notifications or live feeds. Constantly polling the server is inefficient and introduces latency. SSE was created to solve this by allowing the server to push data to the client whenever new information is available, using a standard, long-lived HTTP connection.

The mental model

Think of SSE as a radio broadcast. The server is the radio station, broadcasting updates on a specific frequency (a URL endpoint). Clients are radios that tune into that frequency to listen. They can't talk back to the station; they can only receive the broadcast. This is simpler and often sufficient compared to a telephone call (a WebSocket), where both parties can speak and listen.

How it works

A client initiates a connection by creating an EventSource object in JavaScript, pointing it to a server endpoint. The server accepts this request but keeps the HTTP connection open. It can then send specially formatted text messages down this open connection. Each message can have a data field (the payload) and an optional event field to define custom event types. On the client, you listen for default message events or use addEventListener for your custom event names. The browser handles connection management, including automatically reconnecting if the connection is lost.

When to use it

Use SSE when you need one-way, server-to-client updates. It's perfect for status updates (like a CI/CD pipeline), live dashboards, news tickers, or any scenario where the client subscribes to a stream of information without needing to send data back over the same connection. It's built on standard HTTP and requires less complex server setup than WebSockets.

When not to use it

Do not use SSE if you need two-way, low-latency communication. For applications like chat rooms, collaborative editing tools, or multiplayer games where clients also need to send frequent messages to the server, WebSockets are the appropriate choice. SSE is a one-way street.

One canonical example

The most significant footgun is the browser's limit on the maximum number of open HTTP connections per domain, which is often as low as 6 when using HTTP/1.1. If a user opens seven tabs of your application, and each tab tries to establish an SSE connection, the seventh one will fail to connect and receive updates. This limit is per browser, not per tab. While HTTP/2 mitigates this, it's a critical limitation to be aware of, as browser vendors have marked it as "Won't fix" for HTTP/1.1.