Server-Sent Events and Long Polling

The Most Underrated Browser API

Everyone reaches for WebSocket the moment they need "real-time." But here's the thing most people miss: the majority of real-time features are unidirectional. Notifications, live feeds, stock tickers, build logs, AI chat streaming — the server pushes, the client listens. You don't need a bidirectional channel for that.

Server-Sent Events (SSE) give you exactly this: a persistent HTTP connection where the server streams events to the client. No upgrade handshake, no custom protocol, no library needed. Just EventSource and you're done.

How SSE Works Under the Hood

SSE is just HTTP with a specific content type. The server sets Content-Type: text/event-stream and keeps the connection open, writing events in a simple text format:

event: message
id: 42
data: {"user": "alice", "text": "hello"}

event: typing
id: 43
data: {"user": "bob"}

That's it. Each event is separated by a blank line. The format has four fields:

• data: — The payload. Multiple data: lines are concatenated with newlines.
• event: — Custom event type. Defaults to "message" if omitted.
• id: — Event ID for resumption. The browser sends this back as Last-Event-ID on reconnect.
• retry: — Reconnection delay in milliseconds. The browser respects this.

const eventSource = new EventSource('/api/events');

eventSource.addEventListener('message', (event) => {
  const data = JSON.parse(event.data);
});

eventSource.addEventListener('typing', (event) => {
  const data = JSON.parse(event.data);
});

eventSource.addEventListener('error', (event) => {
  if (eventSource.readyState === EventSource.CONNECTING) {
    // Browser is auto-reconnecting
  }
});

Automatic Reconnection and Resume

This is SSE's killer feature and the reason it should be your default for server-to-client streaming. When the connection drops, the browser:

1. Waits for the retry interval (default ~3 seconds, configurable by server)
2. Reconnects to the same URL
3. Sends Last-Event-ID header with the last received event ID
4. The server can resume from that point

You get all of this for free. No library. No code. The browser just does it.

// Server (Node.js / Express)
app.get('/api/events', (req, res) => {
  res.writeHead(200, {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache',
    Connection: 'keep-alive',
  });

  const lastId = parseInt(req.headers['last-event-id'] ?? '0', 10);

  // Replay missed events
  const missed = getEventsSince(lastId);
  for (const event of missed) {
    res.write(`id: ${event.id}\ndata: ${JSON.stringify(event.data)}\n\n`);
  }

  // Stream new events
  const unsubscribe = eventBus.subscribe((event) => {
    res.write(`id: ${event.id}\ndata: ${JSON.stringify(event.data)}\n\n`);
  });

  req.on('close', unsubscribe);
});

The Fetch-Based SSE Approach

EventSource has limitations: no custom headers (so no Authorization: Bearer ...), no POST method, no request body. For authenticated streams, you need the fetch-based approach using ReadableStream:

async function streamEvents(
  url: string,
  token: string,
  onEvent: (event: { type: string; data: unknown }) => void
) {
  const response = await fetch(url, {
    headers: {
      Authorization: `Bearer ${token}`,
      Accept: 'text/event-stream',
    },
  });

  if (!response.ok || !response.body) {
    throw new Error(`Stream failed: ${response.status}`);
  }

  const reader = response.body.pipeThrough(new TextDecoderStream()).getReader();
  let buffer = '';

  while (true) {
    const { done, value } = await reader.read();
    if (done) break;

    buffer += value;
    const events = buffer.split('\n\n');
    buffer = events.pop() ?? '';

    for (const raw of events) {
      if (!raw.trim()) continue;
      const lines = raw.split('\n');
      let type = 'message';
      let data = '';

      for (const line of lines) {
        if (line.startsWith('event: ')) type = line.slice(7);
        else if (line.startsWith('data: ')) data += (data ? '\n' : '') + line.slice(6);
      }

      onEvent({ type, data: JSON.parse(data) });
    }
  }
}

Long Polling: The Battle-Tested Fallback

Before SSE, before WebSocket, there was long polling. The technique is elegantly simple:

1. Client sends a request
2. Server holds the response open until it has data (or a timeout, typically 30-60 seconds)
3. Server sends the response
4. Client immediately sends a new request
5. Repeat

async function longPoll(
  url: string,
  cursor: string,
  onMessage: (data: unknown, newCursor: string) => void,
  signal: AbortSignal
) {
  while (!signal.aborted) {
    try {
      const res = await fetch(`${url}?cursor=${cursor}`, { signal });
      if (!res.ok) {
        await new Promise((r) => setTimeout(r, 5000));
        continue;
      }
      const { data, nextCursor } = await res.json();
      cursor = nextCursor;
      onMessage(data, nextCursor);
    } catch (err) {
      if (signal.aborted) break;
      await new Promise((r) => setTimeout(r, 5000));
    }
  }
}

Long polling works everywhere. Every HTTP client, every proxy, every CDN understands it. It's the ultimate fallback.

But it has costs: each "event" requires a full HTTP request/response cycle (headers and all), there's inherent latency between when data is available and when the next poll arrives, and each open connection consumes a server thread (or at least a connection slot).

SSE vs WebSocket: When Each Wins

This is not a "which is better" question. It's a "which fits your use case" question.

Use SSE when: notifications, live feeds, build logs, AI streaming responses, dashboards, stock tickers — anything where only the server pushes data.

Use WebSocket when: chat, collaborative editing, multiplayer games, any scenario where the client sends frequent messages to the server.

Use long polling when: SSE isn't available (very rare today), you need maximum compatibility with ancient infrastructure, or your events are infrequent (less than once every few seconds).

Edge Cases That Bite in Production

Proxy Buffering

Some reverse proxies (Nginx, Cloudflare) buffer responses before forwarding them. This kills SSE because the client won't receive events until the buffer fills. The fixes:

# Nginx
location /api/events {
    proxy_buffering off;
    proxy_cache off;
    proxy_set_header Connection '';
    proxy_http_version 1.1;
    chunked_transfer_encoding off;
}

On the server, also send a comment line periodically to keep the connection active:

const keepAlive = setInterval(() => {
  res.write(': keepalive\n\n');
}, 15000);

The : keepalive line (starting with a colon) is a comment in the SSE spec — the browser ignores it, but it keeps intermediaries from closing an "idle" connection.

The HTTP/1.1 Connection Limit

Browsers limit HTTP/1.1 connections to 6 per domain. Each SSE connection counts. If you open 6 SSE streams to the same domain, no other HTTP requests can go through. HTTP/2 multiplexes over a single TCP connection, so this limit doesn't apply — but make sure your infrastructure supports HTTP/2.