Streaming the Web: Why Server-Sent Events Still Matter

Server-Sent Events (SSE)

This is honestly one of my favorite communication patterns (or protocols — however you want to look at it).

It’s based on the classic request/response model, but with a twist:

The response stays open for a very, very long time.

How does SSE work?

When using SSE, the server keeps the response stream open, sending data in chunks as events over time — instead of closing the connection after one response.

Let’s use ChatGPT message streaming as an example:

  1. The client sends a message to the server.

  2. You’ll notice the response comes in chunks, like someone is typing it live.

  3. That’s SSE in action — the server is sending each chunk as it generates it, all through a single, ongoing response stream.

  4. Once the full message is sent, it’s up to you — you can close the connection or keep it open for more events.

In my case, I chose to close the stream after finishing. I’ll explain why in a bit.

Pros of SSE

  1. Works over plain HTTP — using the same request/response pattern we’re already familiar with.

  2. Great for real-time updates.

Cons of SSE

  1. The client must stay online — if the connection drops, you lose the stream.

  2. With HTTP/1.1, browsers like Chrome limit you to 6 open connections per domain.

    So if you’re using SSE and you don’t close the connection after use, you can run into problems quickly, especially on connection-heavy apps.