Wzorzec long pollingu i logika ponownego łączenia

Long polling działa w cyklu: klient wysyła żądanie HTTP, serwer utrzymuje połączenie otwarte do momentu udostępnienia nowych danych (albo wystąpienia limitu czasu, zwykle po 30–60 sekundach), serwer odpowiada danymi, a klient natychmiast wysyła kolejne żądanie. Tworzy to niemal ciągłe połączenie o charakterystyce wypychania danych przez serwer.

Long polling w React wykorzystuje asynchroniczną funkcję rekurencyjną wewnątrz useEffect. Funkcja wykonuje żądanie fetch, przetwarza odpowiedź, a następnie wywołuje samą siebie ponownie. Sygnał AbortController zatrzymuje rekurencję po odmontowaniu komponentu. Funkcja wykonuje kolejne iteracje tak długo, jak długo komponent jest zamontowany i nie zasygnalizowano przerwania.

Na początku useEffect należy utworzyć AbortController i przekazać controller.signal do każdego wywołania fetch. W funkcji sprzątającej należy wywołać controller.abort(). Anuluje to każde trwające żądanie po odmontowaniu komponentu, zapobiegając aktualizowaniu stanu odmontowanych komponentów oraz wyciekom zasobów sieciowych.

Gdy żądanie long pollingu się nie powiedzie, nie należy ponawiać go natychmiast — przed kolejną próbą trzeba odczekać. Wykładniczy backoff podwaja opóźnienie przy każdej kolejnej awarii: 1 s, 2 s, 4 s, 8 s, 16 s, z ograniczeniem do 30 s. Zapobiega to przeciążaniu niesprawnego serwera i daje czas na rozwiązanie przejściowych problemów. Po pomyślnej odpowiedzi należy przywrócić opóźnienie do 1 s.

Gdy wielu klientów odpyta ten sam serwer, wykładniczy backoff bez jittera powoduje efekt „thundering herd”: wszyscy klienci odczekują tyle samo i ponawiają żądania jednocześnie, ponownie przeciążając serwer. Jitter można dodać przez losowe ustalenie opóźnienia: delay + Math.random() * delay. Rozkłada to ponowne próby w określonym przedziale czasu i ogranicza skoki obciążenia serwera.

Należy przechowywać stan połączenia, aby odzwierciedlał cykl życia odpytywania: isConnecting (nawiązywanie początkowego połączenia lub ponowne łączenie po błędzie), isConnected (ostatnie odpytywanie zakończyło się powodzeniem), isError (kolejne awarie, osiągnięto maksymalną liczbę prób). Stan ten należy wyświetlać w interfejsie, aby użytkownicy rozumieli niezawodność danych w czasie rzeczywistym.

Podczas oczekiwania na kolejną próbę w ramach backoffu można wyświetlić odliczanie: „Ponowne łączenie za 8 s...” wraz ze wskaźnikiem postępu. Podczas ustawiania timera backoffu należy obliczyć znacznik czasu ponownej próby i aktualizować wyświetlaną wartość co sekundę. Taka przejrzystość daje użytkownikom pewność, że aplikacja aktywnie próbuje odzyskać połączenie.

Do odpytywania należy używać rekurencyjnego setTimeout (wywołując kolejne odpytywanie w handlerze odpowiedzi), a nie setInterval. setInterval uruchamia funkcję w stałych odstępach, niezależnie od czasu trwania poprzedniego żądania — długotrwałe żądania mogą powodować nakładanie się odpytań. Rekurencyjne setTimeout rozpoczyna kolejne odpytywanie dopiero po zakończeniu poprzedniego.

Interwał odpytywania należy udostępnić jako opcję konfiguracyjną hooka: useLongPoll({ url, interval: 5000 }). Różne źródła danych wymagają różnej aktualności: wskaźnik „kto jest online” może odpytywać serwer co 30 s, a status zadania — co 5 s. Należy unikać zakodowanych na stałe interwałów w kodzie implementacji.

W miarę dojrzewania API można zastąpić odpytywanie przez SSE, aby zwiększyć wydajność. Komponent React korzystający z hooka do odpytywania powinien być odseparowany od warstwy transportowej. Jeśli hook udostępnia ten sam interfejs (onData, status, error), przełączenie z odpytywania na EventSource wewnątrz hooka nie wymaga zmian w komponencie, który z niego korzysta.

Gdy serwer utrzymuje połączenie long pollingu i nie pojawiają się żadne dane, musi odpowiedzieć po upływie limitu czasu (statusem 200 z pustym ciałem albo statusem 204 No Content), aby zapobiec bezterminowemu zawieszeniu połączenia. Klient natychmiast rozpoczyna wtedy kolejne odpytywanie. Ten limit czasu po stronie serwera (30–60 s) jest niezależny od limitu czasu fetch po stronie klienta (dłuższego, np. 90 s).

Dlaczego long polling używa wykładniczego backoffu podczas ponawiania prób po błędach połączenia?

Long polling: klient wysyła żądanie, serwer utrzymuje połączenie do momentu udostępnienia danych lub wystąpienia limitu czasu, a klient natychmiast wysyła kolejne żądanie po otrzymaniu odpowiedzi. Należy użyć rekurencyjnego asynchronicznego fetch w useEffect oraz AbortController do sprzątania. W razie błędu należy zastosować wykładniczy backoff (1 s, 2 s, 4 s... z ograniczeniem do 30 s) wraz z jitterem, aby zapobiec efektowi thundering herd. Należy używać rekurencyjnego setTimeout zamiast setInterval, aby zapobiec nakładaniu się odpytań. Do informacji zwrotnej w interfejsie należy śledzić stan isConnecting/isConnected/isError.