Questions › Networking/Security
You need to push server updates to the browser. Compare long-polling, Server-Sent Events, and WebSockets. How do you choose?
Choosing the right push mechanism by directionality, infrastructure fit, and operational cost — not defaulting to WebSockets reflexively.
HTTP is request/response — the server can't natively initiate — so 'push' needs one of three techniques, and the right choice depends on directionality and how much machinery you want. LONG-POLLING: the client makes a request and the server HOLDS it open until it has data (or a timeout), then responds; the client immediately re-requests. It emulates push over ordinary HTTP, works everywhere (any proxy, any browser), but each message costs a full request/response cycle plus reconnection overhead, and it scales poorly under high message rates. It's the compatibility fallback. SERVER-SENT EVENTS (SSE): a single long-lived HTTP response streams text events from server to client over the EventSource API. It's ONE-DIRECTIONAL (server → client only), which is exactly right for feeds, notifications, live scores, progress updates. Big wins: it's just HTTP (works with HTTP/2 multiplexing, standard infra, CDNs, auth cookies), it AUTO-RECONNECTS and supports resuming via the Last-Event-ID header, and it's simple to implement. Limits: text-only (UTF-8; binary must be encoded), no client→server channel (you still POST normally for that), and over HTTP/1.1 it consumes a connection from the ~6-per-origin budget (HTTP/2 fixes this via multiplexing). WEBSOCKETS: a single TCP connection UPGRADED (via an HTTP Upgrade handshake, 101 Switching Protocols) to a persistent, FULL-DUPLEX, bidirectional channel carrying binary or text frames with minimal per-message overhead. This is the choice when you need low-latency two-way communication: chat, multiplayer games, collaborative editing, live cursors. Costs: it's a different protocol (ws/wss), so it needs infra that understands the upgrade (some proxies/load balancers need config), it doesn't get HTTP caching/semantics, you handle reconnection/heartbeats/backpressure yourself, and auth is trickier (do it during the handshake). How to choose: if updates are one-way server→client, prefer SSE — it's simpler, cheaper, reconnects for free, and rides normal HTTP; reach for WebSockets only when you genuinely need bidirectional or high-frequency client→server messaging; use long-polling as the fallback when neither is available or when message frequency is low and simplicity/compat trumps everything. A frequent mistake is defaulting to WebSockets for a notification feed that SSE would serve with far less operational cost.
Choosing a push mechanism; justifying SSE over WebSockets; building notifications, chat, or live data.
Long-polling SSE (EventSource) WebSocket
Direction server->client server->client only full-duplex (both)
Protocol plain HTTP plain HTTP (stream) ws/wss (Upgrade 101)
Data any text (UTF-8) only text or binary
Reconnect manual re-request auto + Last-Event-ID you implement it
Infra fit universal standard HTTP/CDN/H2 needs upgrade-aware proxies
Per-msg cost full req/response cheap after connect lowest
Choose:
one-way feed/notifications/progress -> SSE (simple, cheap, auto-reconnect)
two-way / high-frequency (chat, games, collab) -> WebSocket
neither available / low rate + max compat -> long-polling
Don't default to WebSockets for a one-way notification feed.