SSE

Server-Sent Events let a server push data to a client whenever it has something new, without the client asking again. The client opens a single HTTP request, the server holds it open, and instead of sending one response and closing, it keeps writing small chunks of text down the same connection.

The browser side is one line of JavaScript: new EventSource('/stream'). That object fires a message event every time the server sends data, plus open and error events. There is no extra protocol to learn and no separate port to manage. It travels over the same HTTP and HTTPS you already use.

The key word is one-way. SSE pushes from server to client only. The client cannot send messages back over the same channel. If the browser needs to talk to the server, it makes a normal separate HTTP request. That limitation is exactly why SSE is simpler than the alternatives.

The server responds with the content type text/event-stream and never closes the body. Each event is plain UTF-8 text in a tiny format: a line starting with data: holds the payload, an optional event: line names the event type, an optional id: line tags the event, and a blank line marks the end of one event. The server can also send retry: to tell the client how long to wait before reconnecting.

Reconnection is built in and automatic. If the connection drops, the browser waits a few seconds and reconnects on its own. It also sends the last id it received in a Last-Event-ID header, so a well-written server can resume from where the client left off instead of replaying everything. You get this resilience for free, which is something WebSockets make you build yourself.

One trap to know about: over HTTP/1.1 a browser allows only about 6 connections per domain, and each open SSE stream eats one of those slots across all tabs. HTTP/2 fixes this by multiplexing many streams over one connection, raising the practical limit to around 100. If you serve SSE at scale, run it over HTTP/2.

Reach for SSE when the data flows mostly in one direction: server to client. Live sports scores, stock tickers, a notification feed, a build or deploy log that streams as it runs, or token-by-token output from an AI model are all natural fits. You get streaming with almost no infrastructure beyond a normal HTTP endpoint.

Use WebSockets instead when you need true two-way, low-latency traffic, like a multiplayer game, a collaborative editor where both sides type, or a chat app with typing indicators. WebSockets are full duplex and can carry binary frames; SSE is text only and one direction.

The trade-off to weigh is simplicity versus capability. SSE works through proxies and firewalls that already understand HTTP, supports automatic reconnect with resume, and needs no special server. The costs are: text only, no client-to-server channel, the per-domain connection limit on HTTP/1.1, and no native support in Internet Explorer (a polyfill covers that if you still care).

ChatGPT and most LLM APIs stream their answers using SSE. When you ask a question, the server does not wait to compute the whole reply. It opens an event stream and sends each token as a separate data: event, which is why you see words appear one at a time. The OpenAI streaming API literally ends the stream with a special data: [DONE] line over text/event-stream.

Picture a stock dashboard. The browser runs const es = new EventSource('/prices'); es.onmessage = e => updateUI(JSON.parse(e.data)). The server pushes a small JSON event each time a price changes. No polling, no WebSocket handshake, and if the user's wifi blips, the browser reconnects and the server resumes from the last event id. That is the whole feature.