You might not need WebSockets

Original Article ↗ Hacker News Discussion ↗

WebSockets and Proxies / Network Environment

  • Multiple commenters note WebSockets work fine through common reverse proxies (nginx, HAProxy, Cloudflare, Fly.io), contradicting any blanket claim that “WebSockets can’t go through proxies.”
  • The real pain point is forward/enterprise proxies and old HTTP CONNECT implementations: some report 5–10% of enterprise clients failing to establish WebSocket connections despite HTTPS working, making debugging and support difficult.

SSE and HTTP Streaming vs WebSockets

  • Many argue that for unidirectional, server→client events (notifications, logs, chat updates), Server-Sent Events (SSE) or raw HTTP streaming are simpler and integrate better with existing HTTP stacks, CDNs, and observability tools.
  • Benefits cited: standard headers, compression, HTTP/2/3 multiplexing, auto-reconnect with Last-Event-ID, easy inspection via browser devtools or curl, simpler load balancing (stateless reconnection to any node).
  • Limitations of SSE mentioned:
    • Text-only; binary requires base64 or another wrapper.
    • Native EventSource cannot set custom headers or use POST, pushing people to custom fetch-based clients.
    • Default infinite reconnect may require explicit “stop” events; some find this helpful for mobile, others find it awkward.
  • Some claim HTTP streaming is being (re)used as a general event stream, not just for chunking large blobs, and that this pattern is increasingly common (LLMs, GraphQL subscriptions, SSE-based tooling).

When WebSockets Are Preferable

  • Pro-WebSocket voices emphasize:
    • Single bidirectional ordered channel simplifies application-level protocols (IDs for request/response, in-order processing, easier recovery after reconnect).
    • Better fit when you genuinely need two‑way, low-latency interaction (games, trading, real-time control) rather than just push.
  • Skeptics counter that mixing SSE (down) + HTTP (up) works well if you design around CQRS and accept looser coupling, and that many “real-time” apps don’t actually need full duplex.

Operational Complexity of WebSockets

  • Common pain points:
    • Stateful connections complicate load balancing (sticky sessions or dedicated WS tier) and deployments (connections dropped on deploy).
    • Need for application‑level heartbeats and reconnection logic; current Chrome behavior delaying close/error events exacerbates this.
    • Some report long-term, mission‑critical WebSocket systems running flawlessly; others describe years of operational headaches (timeouts, proxies, mobile behavior), especially at scale.

Alternatives and Ecosystem

  • Long polling/Comet is still used and easy to implement, but can stress servers and suffers from proxy timeouts and overhead.
  • WebTransport and HTTP/2/3 streams are discussed as more modern options, but support (notably Safari, some reverse proxies) is incomplete.
  • Libraries/frameworks (socket.io and others) are repeatedly mentioned as hiding much of WebSocket’s handshake, reconnection, and fallback complexity; several commenters feel the article underplays that.