Long Polling
Polling where the server keeps each request waiting until new data arrives or a timeout forces the client to reconnect.
See it
What it is
Long polling asks for new data, but instead of answering immediately with 'nothing yet', the server holds the HTTP request open until an event arrives or a timeout expires. As soon as the response finishes, the client opens another request. It was widely known as a hanging GET, or as part of the Comet family, the name Alex Russell coined in 2006 for the push tricks browsers used before WebSocket existed.
Reach for it when ordinary polling feels too laggy or wasteful but webhooks, Server-Sent Events, or WebSocket are unavailable. It works through most HTTP infrastructure and gives near-immediate updates with a conventional request-response API, which makes it useful for modest notification or job-status traffic.
The timeout chain is the trap. A proxy, load balancer, server, or client may close an idle request before your application does. Set an application timeout below the shortest infrastructure timeout, send a cursor so reconnects do not miss events, cancel abandoned requests, and add jitter before reconnecting after errors so a recovery does not wake every client at once.
Ask AI for it
Implement long polling for GET /api/events using an event cursor. Hold each request for at most 25 seconds, return 200 with all events after the cursor as soon as one exists, and return 204 on timeout. On the client, issue the next Fetch API request only after the previous one finishes, advance the cursor after processing, cancel with AbortController on unmount, and retry network failures with exponential backoff plus jitter. Set Nginx proxy_read_timeout above 25 seconds.