Modèle d’interrogation longue et logique de reconnexion

L’interrogation longue fonctionne selon un cycle : le client envoie une requête HTTP, le serveur maintient la connexion ouverte jusqu’à ce que de nouvelles données soient disponibles (ou qu’un délai d’expiration survienne, généralement après 30 à 60 secondes), le serveur renvoie les données, puis le client envoie immédiatement une nouvelle requête. Cela crée une connexion presque continue, avec des caractéristiques d’envoi des données par le serveur.

Dans React, l’interrogation longue utilise une fonction asynchrone récursive à l’intérieur de useEffect. La fonction effectue une requête, traite la réponse, puis s’appelle à nouveau. Un signal d’annulation AbortController arrête la récursion lorsque le composant est démonté. La fonction boucle tant que le composant est monté et qu’aucune demande d’annulation n’a été signalée.

Créez un AbortController au début de useEffect et transmettez controller.signal à chaque appel de requête. Dans la fonction de nettoyage, appelez controller.abort(). Cela annule toute requête en cours lorsque le composant est démonté, évitant ainsi les mises à jour d’état sur des composants démontés et les fuites de ressources réseau.

Lorsqu’une requête d’interrogation longue échoue, ne réessayez pas immédiatement : attendez avant la tentative suivante. La temporisation exponentielle double le délai après chaque échec consécutif : 1 s, 2 s, 4 s, 8 s, 16 s, avec un plafond de 30 s. Cela évite de surcharger un serveur défaillant et lui laisse le temps de résoudre les problèmes temporaires. Réinitialisez le délai à 1 s après une réponse réussie.

Lorsque de nombreux clients interrogent le même serveur, une temporisation exponentielle sans variation aléatoire provoque un « effet de troupeau » : tous les clients attendent la même durée et réessaient simultanément, ce qui surcharge de nouveau le serveur. Ajoutez une variation aléatoire en modifiant le délai ainsi : delay + Math.random() * delay. Les nouvelles tentatives sont ainsi réparties sur une période donnée, ce qui réduit les pics de charge du serveur.

Conservez l’état de la connexion afin de refléter le cycle de vie de l’interrogation : isConnecting (connexion initiale ou reconnexion après une erreur), isConnected (dernière interrogation réussie), isError (échecs consécutifs, nombre maximal de tentatives atteint). Affichez cet état dans l’interface afin que les utilisateurs comprennent la fiabilité des données en temps réel.

Pendant le délai d’attente avant la nouvelle tentative, vous pouvez afficher un compte à rebours : « Reconnexion dans 8 secondes… » accompagné d’un indicateur de progression. Calculez l’horodatage de la nouvelle tentative lorsque vous configurez le minuteur de temporisation, puis mettez l’affichage à jour chaque seconde. Cette transparence rassure les utilisateurs en leur montrant que l’application tente activement de rétablir la connexion.

Utilisez setTimeout de manière récursive (appelez l’interrogation suivante dans le gestionnaire de réponse) plutôt que setInterval. setInterval se déclenche à intervalles fixes, quelle que soit la durée de la requête précédente : les requêtes longues peuvent ainsi provoquer des interrogations simultanées. Avec setTimeout récursif, l’interrogation suivante ne commence qu’une fois la précédente terminée.

Exposez l’intervalle d’interrogation comme option de configuration de votre fonction : useLongPoll({ url, interval: 5000 }). Les différentes sources de données n’exigent pas la même fraîcheur : un indicateur des utilisateurs connectés peut interroger le serveur toutes les 30 secondes, tandis que l’état d’une tâche peut être vérifié toutes les 5 secondes. Évitez de coder les intervalles en dur dans le code d’implémentation.

À mesure que votre API évolue, vous pouvez remplacer l’interrogation par SSE pour gagner en efficacité. Le composant React qui utilise une fonction d’interrogation doit être découplé de la couche de transport. Si votre fonction expose la même interface (onData, état, erreur), remplacer l’interrogation par EventSource en interne ne nécessite aucune modification du composant qui l’utilise.

Lorsque le serveur maintient une connexion d’interrogation longue et qu’aucune donnée n’arrive, il doit répondre avec un délai d’expiration (200 avec un corps vide ou 204 sans contenu) afin d’éviter que la connexion ne reste bloquée indéfiniment. Le client lance alors immédiatement une nouvelle interrogation. Ce délai d’expiration côté serveur (30 à 60 secondes) est distinct du délai d’expiration des requêtes côté client, qui est plus long, par exemple 90 secondes.

Pourquoi l’interrogation longue utilise-t-elle une temporisation exponentielle lors des nouvelles tentatives après des erreurs de connexion ?

Interrogation longue : le client envoie une requête, le serveur attend que des données soient disponibles ou qu’un délai d’expiration survienne, puis le client envoie immédiatement une nouvelle requête après la réponse. Implémentez-la avec une requête asynchrone récursive dans useEffect et AbortController pour le nettoyage. En cas d’erreur : utilisez une temporisation exponentielle (1 s, 2 s, 4 s… avec un plafond de 30 s) ainsi qu’une variation aléatoire pour éviter l’effet de troupeau. Préférez setTimeout récursif à setInterval afin d’éviter les interrogations simultanées. Suivez l’état isConnecting/isConnected/isError pour informer l’utilisateur.