Backend
Long Polling
The client sends a request and the server holds it open until data is ready or a timeout fires, then the client immediately re-requests — simulating push over plain HTTP. Use it as a fallback where WebSockets and SSE are unavailable. It is simple but wastes connections and adds latency versus a real streaming transport.
Purpose
Long polling emulates server push over ordinary HTTP: the client makes a request and the server holds it open until it has data (or a timeout), then the client immediately requests again. It exists as a fallback for near-real-time updates where WebSockets and SSE are not available.
When to Use It
Useful behind restrictive proxies or on old clients that block streaming transports, and as a graceful degradation path. It is acceptable for low-frequency updates such as notifications.
For anything high-frequency or bidirectional, prefer WebSockets or SSE — long polling wastes connections and adds latency.
Trade-offs
It works almost everywhere HTTP does, but each update costs a full request/response cycle, ties up a server connection while it waits, and adds a round-trip of latency compared with a true stream.
Implementation
On the server, park the request asynchronously (without blocking a thread) until an event arrives or a timeout — say 30 seconds — fires, then respond; the client re-requests at once, passing a cursor or last-seen id so nothing is missed. Set sensible timeouts and connection limits to avoid resource exhaustion.