Long-Polling-Muster und Wiederverbindungslogik

Long Polling läuft in einem Zyklus ab: Der Client sendet eine HTTP-Anfrage, der Server hält die Verbindung offen, bis neue Daten verfügbar sind (oder eine Zeitüberschreitung eintritt, typischerweise nach 30–60 Sekunden), der Server antwortet mit den Daten und der Client sendet sofort eine weitere Anfrage. Dadurch entsteht eine nahezu kontinuierliche Verbindung mit Eigenschaften einer Server-Push-Verbindung.

Long Polling in React verwendet eine asynchrone rekursive Funktion innerhalb von useEffect. Die Funktion sendet eine fetch-Anfrage, verarbeitet die Antwort und ruft sich anschließend erneut auf. Ein AbortController-Signal beendet die Rekursion, wenn die Komponente aus dem DOM entfernt wird. Die Funktion läuft weiter, solange die Komponente eingebunden ist und kein Abbruch signalisiert wurde.

Erstellen Sie am Anfang von useEffect einen AbortController und übergeben Sie controller.signal an jeden fetch-Aufruf. Rufen Sie in der Bereinigungsfunktion controller.abort() auf. Dadurch wird eine laufende Anfrage beim Entfernen der Komponente abgebrochen. Zustandsaktualisierungen bei nicht mehr eingebundenen Komponenten und Leaks von Netzwerkressourcen werden verhindert.

Wenn eine Long-Polling-Anfrage fehlschlägt, versuchen Sie es nicht sofort erneut, sondern warten Sie vor dem nächsten Versuch. Beim exponentiellen Backoff wird die Wartezeit nach jedem aufeinanderfolgenden Fehler verdoppelt: 1 s, 2 s, 4 s, 8 s, 16 s, begrenzt auf 30 s. Dadurch wird verhindert, dass ein fehlerhafter Server mit Anfragen überlastet wird, und vorübergehende Probleme erhalten Zeit, sich zu lösen. Setzen Sie die Wartezeit nach einer erfolgreichen Antwort auf 1 s zurück.

Wenn viele Clients denselben Server abfragen, führt exponentielles Backoff ohne Jitter zum sogenannten „Thundering-Herd-Problem“: Alle Clients warten gleich lange und versuchen es gleichzeitig erneut, wodurch der Server wieder überlastet wird. Fügen Sie Jitter hinzu, indem Sie die Wartezeit zufällig bestimmen: delay + Math.random() * delay. Dadurch verteilen sich die neuen Versuche über ein Zeitfenster und Lastspitzen auf dem Server werden reduziert.

Verwalten Sie den Zustand des Verbindungsstatus, um den Lebenszyklus des Pollings abzubilden: isConnecting (initiale Verbindung oder Wiederverbindung nach einem Fehler), isConnected (letzter Polling-Versuch erfolgreich), isError (aufeinanderfolgende Fehler, maximale Anzahl von Versuchen erreicht). Zeigen Sie diesen Status in der Benutzeroberfläche an, damit Benutzer die Zuverlässigkeit der Echtzeitdaten einschätzen können.

Während der Backoff-Wartezeit vor dem nächsten Versuch können Sie einen Countdown wie „Wiederverbindung in 8 s …“ mit einer Fortschrittsanzeige einblenden. Berechnen Sie beim Setzen des Backoff-Timers den Zeitpunkt des nächsten Versuchs und aktualisieren Sie die Anzeige jede Sekunde. Diese Transparenz vermittelt Benutzern, dass die Anwendung aktiv versucht, die Verbindung wiederherzustellen.

Verwenden Sie für Polling ein rekursives setTimeout (starten Sie den nächsten Polling-Versuch im Antwort-Handler) statt setInterval. setInterval wird unabhängig von der Dauer der vorherigen Anfrage in festen Abständen ausgeführt – lang laufende Anfragen können zu überlappenden Polling-Versuchen führen. Das rekursive setTimeout startet den nächsten Polling-Versuch erst, nachdem der vorherige abgeschlossen ist.

Machen Sie das Polling-Intervall als Konfigurationsoption in Ihrem Hook verfügbar: useLongPoll({ url, interval: 5000 }). Verschiedene Datenquellen benötigen unterschiedliche Aktualisierungsraten: Eine Anzeige, wer online ist, könnte alle 30 s abgefragt werden, während der Status einer Aufgabe alle 5 s abgefragt werden könnte. Vermeiden Sie fest codierte Intervalle im Implementierungscode.

Wenn Ihre API ausgereifter ist, können Sie Polling für eine bessere Effizienz durch SSE ersetzen. Die React-Komponente, die einen Polling-Hook verwendet, sollte von der Transportschicht abstrahiert sein. Wenn Ihr Hook dieselbe Schnittstelle bereitstellt (onData, status, error), sind beim Wechsel von Polling zu EventSource im Hintergrund keine Änderungen an der Komponente erforderlich, die den Hook verwendet.

Wenn der Server eine Long-Polling-Verbindung offen hält und keine Daten eintreffen, muss er mit einem Timeout antworten (200 mit leerem Body oder 204 No Content), damit die Verbindung nicht auf unbestimmte Zeit offen bleibt. Der Client startet anschließend sofort einen neuen Polling-Versuch. Dieses serverseitige Timeout (30–60 s) ist vom clientseitigen fetch-Timeout (länger, z. B. 90 s) unabhängig.

Warum verwendet Long Polling beim erneuten Versuch nach Verbindungsfehlern ein exponentielles Backoff?

Long Polling: Der Client sendet eine Anfrage, der Server hält die Verbindung offen, bis Daten verfügbar sind oder ein Timeout eintritt, und der Client sendet unmittelbar nach der Antwort eine neue Anfrage. Implementieren Sie dies mit einem rekursiven asynchronen fetch in useEffect und einem AbortController zur Bereinigung. Bei Fehlern: exponentielles Backoff (1 s, 2 s, 4 s …, begrenzt auf 30 s) plus Jitter, um das Thundering-Herd-Problem zu vermeiden. Verwenden Sie ein rekursives setTimeout statt setInterval, um überlappende Polling-Versuche zu verhindern. Verfolgen Sie den Zustand von isConnecting/isConnected/isError, um entsprechendes Feedback in der Benutzeroberfläche anzuzeigen.