Patrón de long polling y lógica de reconexión

El long polling funciona en un ciclo: el cliente envía una solicitud HTTP, el servidor mantiene abierta la conexión hasta que hay nuevos datos (o se produce un tiempo de espera, normalmente de 30 a 60 segundos), el servidor responde con los datos y el cliente envía inmediatamente otra solicitud. Esto crea una conexión casi continua con características de envío desde el servidor.

El long polling en React utiliza una función asíncrona recursiva dentro de useEffect. La función realiza una solicitud fetch, procesa la respuesta y luego se vuelve a llamar. Una señal de AbortController detiene la recursión cuando el componente se desmonta. La función se repite mientras el componente esté montado y no se haya indicado una cancelación.

Cree un AbortController al principio de useEffect y pase controller.signal a cada llamada a fetch. En la función de limpieza, llame a controller.abort(). Esto cancela cualquier solicitud en curso cuando el componente se desmonta, evita actualizaciones de estado en componentes desmontados y previene fugas de recursos de red.

Cuando falla una solicitud de long polling, no la reintente de inmediato: espere antes del siguiente intento. El backoff exponencial duplica el retraso en cada fallo consecutivo: 1 s, 2 s, 4 s, 8 s, 16 s, con un límite de 30 s. Esto evita sobrecargar un servidor que está fallando y le da tiempo para resolver problemas transitorios. Restablezca el retraso a 1 s cuando la respuesta sea correcta.

Cuando muchos clientes consultan el mismo servidor, el backoff exponencial sin jitter provoca el efecto de avalancha (thundering herd): todos los clientes esperan el mismo tiempo y reintentan simultáneamente, lo que vuelve a sobrecargar el servidor. Añada jitter aleatorizando el retraso: delay + Math.random() * delay. Esto distribuye los reintentos en un intervalo de tiempo y reduce los picos de carga del servidor.

Mantenga un estado que refleje el ciclo de vida del sondeo: isConnecting (conexión inicial o reconexión después de un error), isConnected (el último sondeo se realizó correctamente), isError (fallos consecutivos, se alcanzó el número máximo de reintentos). Muestre este estado en la interfaz para que los usuarios comprendan la fiabilidad de los datos en tiempo real.

Durante el retraso de backoff antes del siguiente reintento, puede mostrar una cuenta atrás: «Reconectando en 8 s...» junto con un indicador de progreso. Calcule la marca de tiempo del reintento al configurar el temporizador de backoff y actualice la pantalla cada segundo. Esta transparencia garantiza a los usuarios que la aplicación intenta recuperarse activamente.

Utilice setTimeout recursivo (inicie el siguiente sondeo dentro del controlador de respuesta) en lugar de setInterval para realizar el sondeo. setInterval se ejecuta en intervalos fijos independientemente de cuánto tarde la solicitud anterior; las solicitudes de larga duración pueden provocar sondeos superpuestos. setTimeout recursivo solo inicia el siguiente sondeo después de que finaliza el anterior.

Exponga el intervalo de sondeo como una opción de configuración de su hook: useLongPoll({ url, interval: 5000 }). Cada fuente de datos necesita un nivel de actualización diferente: un indicador de quién está conectado podría consultarse cada 30 s, mientras que el estado de una tarea podría consultarse cada 5 s. Evite codificar los intervalos directamente en el código de implementación.

A medida que su API madure, podría sustituir el sondeo por SSE para mejorar la eficiencia. El componente React que utiliza un hook de sondeo debería estar abstraído de la capa de transporte. Si su hook expone la misma interfaz (onData, status, error), cambiar del sondeo a EventSource internamente no requiere cambios en el componente que consume el hook.

Cuando el servidor mantiene una conexión de long polling abierta y no llegan datos, debe responder con un tiempo de espera (200 con un cuerpo vacío o 204 No Content) para evitar que la conexión permanezca abierta indefinidamente. Después, el cliente vuelve a realizar el sondeo inmediatamente. Este tiempo de espera del servidor (30-60 s) es independiente del tiempo de espera de fetch en el cliente (más largo, por ejemplo, de 90 s).

¿Por qué utiliza backoff exponencial el long polling al reintentar después de errores de conexión?

Long polling: el cliente realiza una solicitud, el servidor la mantiene abierta hasta que hay datos disponibles o se agota el tiempo de espera, y el cliente vuelve a solicitar datos inmediatamente después de la respuesta. Impleméntelo con una llamada fetch asíncrona recursiva en useEffect y AbortController para la limpieza. En caso de error: utilice backoff exponencial (1 s, 2 s, 4 s... con un límite de 30 s) más jitter para evitar el efecto de avalancha. Use setTimeout recursivo en lugar de setInterval para evitar sondeos superpuestos. Realice un seguimiento de los estados isConnecting/isConnected/isError para proporcionar información en la interfaz.