Stop using WebSockets for everything
Choose SSE, long polling, or WebSockets based on the direction, frequency, and latency your real-time feature actually needs.
“Real-time” is a requirement, not a transport. The right choice depends on who needs to send updates, how often they happen, and how quickly the other side must react. A persistent two-way socket is powerful, but most live interfaces need much less machinery.
Server-Sent Events
SSE fits when updates travel in one direction: the backend produces events and the browser listens. It uses a normal HTTP response, has a simple browser API, and reconnects automatically. That makes it a natural match for streaming model output or reporting the progress of work that was started earlier.
Long polling
Long polling keeps the request-response model. The browser asks for a status, the server waits until something changes or the request times out, and the browser immediately asks again. It is deliberately boring—and for payment confirmation, order tracking, or occasional webhook-driven changes, boring is often the resilient choice.
WebSockets
WebSockets earn their complexity when both sides are active peers and every round trip matters. A game lobby, collaborative canvas, or busy voice-and-chat room continuously exchanges state in both directions. Here, one long-lived connection is not incidental infrastructure; it is the feature’s communication channel.