Что такое Long Polling

Long Polling помогает в ситуации, когда серверу нужно сообщить клиенту о новом событии, но постоянное WebSocket-соединение не используется. Клиент делает обычный HTTP-запрос, например на endpoint уведомлений. Если новых событий нет, сервер держит запрос открытым.

Когда событие появляется, сервер отвечает данными. Если событие не появилось за заданное время, сервер завершает запрос по таймауту, часто пустым ответом. После любого штатного завершения клиент начинает следующий запрос.

Короткая формулировка для интервью:

Long Polling это цикл HTTP-запросов, где сервер отвечает не сразу, а когда появились данные или истек таймаут. Клиент после ответа запускает следующий запрос и получает обновления почти в реальном времени.

При обычном polling клиент ходит на сервер по расписанию. Например, раз в секунду, раз в пять секунд или раз в минуту. Сервер отвечает сразу, даже если данных нет. Это просто, но часто дает много пустых запросов и лишнюю задержку. Событие может появиться сразу после проверки, а клиент узнает о нем только на следующем тике.

При Long Polling запрос может висеть до события. Если событие появилось через 200 мс, клиент получит его почти сразу. Если ничего не произошло, запрос закроется по таймауту и начнется новый цикл.

Практический вывод простой. Long Polling уменьшает число пустых ответов и среднюю задержку для редких событий, но не убирает стоимость HTTP-запросов полностью.

На интервью сильный ответ не заканчивается фразой, что это альтернатива WebSocket. Лучше сразу показать границы выбора. Long Polling подходит не потому, что он современнее. Он полезен, когда HTTP-цепочка проще проходит через инфраструктуру и достаточно хороша для редких событий.

Во фронтенде Long Polling опасен не самим fetch, а бесконечным циклом вокруг него. Важно не запустить несколько циклов случайно. Еще важно не потерять событие между запросами и не продолжать работу после ухода пользователя со страницы.

Пример ниже показывает общий подход. Это не универсальная библиотека, а схема. Один активный запрос, курсор, отмена через AbortController и пауза при ошибке. В URL передается только несекретный cursor, а не токен доступа.

import { useEffect } from "react";

function useNotificationsPolling() {
  useEffect(() => {
    const controller = new AbortController();
    let stopped = false;
    let cursor: string | null = null;

    async function loop() {
      while (!stopped) {
        try {
          const url = new URL("/api/notifications/long-poll", window.location.origin);

          if (cursor) {
            url.searchParams.set("cursor", cursor);
          }

          const response = await fetch(url, { signal: controller.signal });

          if (response.status === 204) {
            continue;
          }

          if (response.status === 401 || response.status === 403) {
            // requestLogin();
            return;
          }

          if (!response.ok) {
            throw new Error(`Request failed: ${response.status}`);
          }

          const payload = await response.json();

          cursor = payload.cursor;
          // updateNotifications(payload.items);
        } catch (error) {
          if (controller.signal.aborted) {
            return;
          }

          await new Promise((resolve) => setTimeout(resolve, 1000));
        }
      }
    }

    loop();

    return () => {
      stopped = true;
      controller.abort();
    };
  }, []);
}

В реальном проекте retry лучше делать с backoff и jitter. Ошибки авторизации стоит обрабатывать отдельно. Если токен истек, бесконечно повторять запрос бессмысленно. Нужно обновить сессию или вернуть пользователя к логину. Данные из ответа нельзя вставлять в HTML без очистки. Уведомления и сообщения приходят с сервера, поэтому опасная разметка может стать XSS.

Таймаут без данных это штатный результат. Сервер не обязан держать запрос бесконечно. Есть лимиты прокси, балансировщика, приложения и браузера. Клиент должен спокойно начать следующий запрос.

Сетевые ошибки и ответы 5xx лучше считать временной проблемой. Но не повторяйте запрос мгновенно без конца. Иначе при деградации сервера тысячи клиентов начнут стучаться еще чаще.

Для порядка событий нужен контракт приложения. Обычно клиент отправляет lastEventId или cursor, а сервер возвращает события после этой точки. Тогда клиент может пережить короткий обрыв, перезагрузку вкладки или дубль ответа без потери данных. Обработчик на клиенте должен быть идемпотентным. Если событие пришло повторно, UI не должен показать второе одинаковое уведомление.

Frontend Developer не обязан проектировать сервер целиком, но на интервью полезно показать понимание цены решения. Long Polling держит открытые соединения. Значит сервер, прокси и балансировщик должны быть к этому готовы.

Можно сказать так:

Я понимаю, что Long Polling выглядит просто на клиенте, но на сервере нужны корректные таймауты, лимиты, освобождение ресурсов и поддержка long-lived запросов в прокси. Иначе решение будет работать в демо, но начнет ломаться под нагрузкой.

Такой ответ звучит сильнее, чем простое перечисление WebSocket и SSE. Вы показываете, что думаете о продакшен-рисках.

Если вас спрашивают, что такое Long Polling, начните с механики одного запроса. Потом сразу добавьте цикл. Ответ получили, запускаете следующий запрос. После этого покажите разницу с polling и границы выбора рядом с WebSocket и SSE.

Хороший короткий ответ занимает 4-6 предложений. Не уходите в историю realtime-технологий. Достаточно объяснить поведение, последствия для UI и ошибки, которые вы бы обработали в коде.