Padrão de sondagem longa e lógica de reconexão

A consulta longa funciona em um ciclo: o cliente envia uma solicitação HTTP, o servidor mantém a conexão aberta até que novos dados estejam disponíveis (ou ocorra um tempo limite, normalmente de 30 a 60 segundos), o servidor responde com os dados e o cliente inicia imediatamente outra solicitação. Isso cria uma conexão quase contínua com características de envio pelo servidor.

A consulta longa no React usa uma função assíncrona recursiva dentro de useEffect. A função faz uma solicitação, processa a resposta e então chama a si mesma novamente. Um sinal de AbortController interrompe a recursão quando o componente é desmontado. A função continua repetindo enquanto o componente estiver montado e nenhum sinal de interrupção tiver sido emitido.

Crie um AbortController no início do useEffect e passe controller.signal para cada chamada de busca. Na função de limpeza, chame controller.abort(). Isso cancela qualquer solicitação em andamento quando o componente é desmontado, impedindo atualizações de estado em componentes desmontados e vazamentos de recursos de rede.

Quando uma solicitação de consulta longa falhar, não tente novamente imediatamente — aguarde antes da próxima tentativa. A espera exponencial duplica o atraso a cada falha consecutiva: 1 s, 2 s, 4 s, 8 s, 16 s, limitando-o a 30 s. Isso evita sobrecarregar um servidor com falhas e permite que problemas temporários sejam resolvidos. Redefina o atraso para 1 s após uma resposta bem-sucedida.

Quando muitos clientes consultam o mesmo servidor, a espera exponencial sem variação causa um efeito manada: todos os clientes aguardam o mesmo período e tentam novamente simultaneamente, sobrecarregando o servidor outra vez. Adicione variação tornando o atraso aleatório: delay + Math.random() * delay. Isso distribui as novas tentativas ao longo de um intervalo de tempo, reduzindo picos de carga no servidor.

Mantenha o estado da conexão para refletir o ciclo de vida da consulta: isConnecting (conexão inicial ou reconexão após um erro), isConnected (última consulta bem-sucedida), isError (falhas consecutivas, número máximo de tentativas atingido). Exiba esse estado na interface para que os usuários entendam a confiabilidade dos dados em tempo real.

Durante o atraso antes da próxima tentativa, você pode mostrar uma contagem regressiva: "Reconectando em 8 s..." com um indicador de progresso. Calcule o instante da próxima tentativa ao configurar o temporizador de espera e atualize a exibição a cada segundo. Essa transparência tranquiliza os usuários, mostrando que o aplicativo está tentando se recuperar ativamente.

Use setTimeout recursivo (chame a próxima consulta dentro do manipulador de resposta) em vez de setInterval para fazer consultas. setInterval é acionado em intervalos fixos, independentemente de quanto tempo a solicitação anterior levou — solicitações demoradas podem causar consultas sobrepostas. O setTimeout recursivo só inicia a próxima consulta depois que a anterior é concluída.

Exponha o intervalo de consulta como uma opção de configuração no seu gancho: useLongPoll({ url, interval: 5000 }). Diferentes fontes de dados precisam de diferentes níveis de atualização: um indicador de quem está online pode fazer uma consulta a cada 30 s, enquanto o estado de uma tarefa pode ser consultado a cada 5 s. Evite fixar os intervalos no código de implementação.

À medida que sua API amadurece, talvez você substitua a consulta longa por SSE para obter mais eficiência. O componente React que usa um gancho de consulta deve ser abstraído da camada de transporte. Se o seu gancho expuser a mesma interface (onData, estado, erro), a troca da consulta longa por EventSource internamente não exigirá alterações no componente que consome o gancho.

Quando o servidor mantém uma conexão de consulta longa e nenhum dado chega, ele deve responder com um tempo limite (200 com corpo vazio ou 204 Sem conteúdo) para evitar que a conexão fique aguardando indefinidamente. Em seguida, o cliente faz outra consulta imediatamente. Esse tempo limite no servidor (30 a 60 s) é separado do tempo limite da busca no cliente (mais longo, por exemplo, 90 s).

Por que a consulta longa usa uma espera exponencial ao tentar novamente após erros de conexão?

Consulta longa: o cliente faz uma solicitação, o servidor aguarda até que haja dados ou ocorra um tempo limite, e o cliente faz uma nova solicitação imediatamente após a resposta. Implemente com uma função assíncrona recursiva que faça buscas em useEffect e use AbortController para a limpeza. Em caso de erro: espera exponencial (1 s, 2 s, 4 s... limitada a 30 s) mais variação para evitar o efeito manada. Prefira setTimeout recursivo a setInterval para impedir consultas sobrepostas. Acompanhe o estado isConnecting/isConnected/isError para fornecer informações na interface.