Server-Sent Events (SSE) Are Underrated
Use cases and libraries
- Used for streaming hypermedia UIs, chatbots/LLMs, log tailing, hot reloading, and CLI “auto-restart on config change”.
- Several dedicated systems built around SSE: frontend frameworks, pub/sub hubs, and realtime servers that support multiple transports (SSE, HTTP streaming, WebSockets, gRPC).
- SSE often chosen when only server→client updates are needed, especially in stacks where WebSockets are heavier to integrate.
Perceived advantages
- Very simple to set up on the server; often “a few lines” in common web frameworks.
- Browser
EventSourceAPI provides automatic reconnection and ID-based resumption. - Plays well with HTTP/2 and HTTP/3, giving efficient multiplexing and avoiding connection limits.
- Often works better than WebSockets through corporate proxies/firewalls and some network middleboxes.
- More bandwidth- and battery-efficient than polling, since it avoids repeated HTTP headers and connections.
Major limitations and ecosystem issues
- On HTTP/1.1, browsers cap open SSE connections per origin (~6), causing failures with many tabs; no clean client-side way to detect hitting the limit.
- Some corporate networks downgrade or MITM TLS and only support HTTP/1.1, breaking the “just use HTTP/2” fix.
- Some load balancers, proxies, tunnels, and FaaS platforms buffer or time out long-lived HTTP responses, making SSE unreliable unless tuned (pings, timeouts, flush behavior).
- No binary framing; everything is text. Newline-based framing and the
data:prefix can conflict with raw text payloads, requiring encoding and robust parsers. - Native browser
EventSourcelacks Authorization header support, pushing people to polyfills or custom streaming clients. - Mobile/background behavior and battery cost of frequent pings are problematic and not fully resolved.
Patterns and workarounds
- Use a single SSE connection per origin and multiplex logical channels over it.
- Coordinate multiple tabs via BroadcastChannel or Web Locks; possibly centralize the SSE connection in a worker.
- Some prefer generic HTTP streaming with
ReadableStreamand custom length-prefixed or ndjson framing over SSE’s fixed format.
SSE vs WebSockets
- Supporters argue SSE is simpler, more compatible with existing HTTP infra, and good enough for unidirectional updates.
- Skeptics argue WebSockets are ubiquitous, easy to constrain to one direction, and that SSE’s edge cases (infra quirks, framing, limits) reduce its appeal.