Apprenez quand le streaming gRPC est préférable au polling REST, avec des exemples concrets pour tableaux de bord live et mises à jour de progression, plus des notes pour mobile et pare‑feu.
Le polling signifie que le client demande au serveur des mises à jour encore et encore, généralement sur un minuteur (toutes les 1 seconde, 5 secondes, 30 secondes).
Le streaming signifie que le client ouvre une connexion unique et que le serveur envoie des mises à jour au fur et à mesure, sans attendre la prochaine requête.
Cette différence unique explique pourquoi streaming et polling peuvent sembler similaires dans une petite démo mais se comporter très différemment dans un vrai produit. Avec le polling, vous faites d'entrée un compromis : des mises à jour plus rapides signifient plus de requêtes. Avec le streaming, vous gardez une ligne ouverte et n'envoyez que lorsque quelque chose change réellement.
En pratique, quelques points ont tendance à peser :
Le polling n'est aussi frais que l'intervalle choisi, tandis que le streaming peut sembler quasi instantané. Le polling produit aussi beaucoup de réponses « rien n'a changé », ce qui ajoute du coût des deux côtés (requêtes, en-têtes, vérifications d'authentification, parsing). Sur mobile, un polling fréquent maintient la radio éveillée plus souvent, ce qui peut consommer batterie et données. Et parce que le polling échantillonne l'état, il peut manquer des changements rapides entre les intervalles, alors qu'un flux bien conçu peut livrer les événements dans l'ordre.
Un exemple simple : un tableau de bord opérationnel en direct montrant de nouvelles commandes et leur statut. Poller toutes les 10 secondes peut convenir un jour calme. Mais quand l'équipe attend des mises à jour en moins d'une seconde, le polling paraît lent ou commence à surcharger le serveur.
Toutes les applications n'ont pas besoin du temps réel. Si les utilisateurs consultent une page de temps en temps (rapports mensuels), un polling chaque minute, ou simplement un rafraîchissement manuel, est souvent le choix le plus simple et le meilleur.
Le polling paraît simple : le client demande « y a‑t‑il du nouveau ? » toutes les N secondes. Ça marche quand les mises à jour sont rares, le nombre d'utilisateurs faible, ou quand quelques secondes de retard n'ont pas d'importance.
La douleur commence quand vous avez besoin d'une fraîcheur fréquente, beaucoup d'utilisateurs, ou les deux.
Les tableaux de bord en direct en sont le cas classique. Pensez à un écran ops montrant tickets ouverts, échecs de paiement et alertes rouges. Si les chiffres changent toutes les quelques secondes, le polling soit traîne (les utilisateurs manquent les pics) soit inonde votre API (vos serveurs passent du temps à répondre « pas de changement » encore et encore).
Les mises à jour de progression sont un autre piège courant. Importations de fichiers, génération de rapports et traitement vidéo durent souvent des minutes. Poller chaque seconde donne l'impression d'un UI « en direct », mais ça crée beaucoup de requêtes supplémentaires et reste saccadé car le client ne voit que des instantanés.
Les arrivées imprévisibles rendent aussi le polling coûteux. Chat, files de support et nouvelles commandes peuvent être calmes pendant 10 minutes, puis en rafale pendant 30 secondes. Avec le polling, vous payez le coût durant la période calme, et vous risquez toujours des délais pendant l'explosion.
Les signaux de type IoT aggravent le problème. Quand vous suivez l'état en ligne/hors ligne d'appareils, le dernier seen et de petites métriques, vous pouvez avoir des milliers de petits changements qui s'accumulent. Le polling multiplie cela en un flux constant de requêtes.
Le polling commence généralement à poser problème quand vous observez des patterns comme : des équipes abaissent l'intervalle à 1–2 secondes juste pour paraître réactives ; la plupart des réponses ne contiennent pas de mises à jour mais consomment en-têtes et authentification ; la charge serveur augmente avec les onglets ouverts au lieu de vrais changements ; les utilisateurs mobiles se plaignent de batterie et de data ; les pics de trafic se produisent quand les gens ouvrent des tableaux de bord, pas quand les événements métiers surviennent.
Le principal avantage du streaming est simple : vous arrêtez de poser la même question au serveur quand la réponse est généralement « pas de changement ». Avec le polling, votre appli envoie des requêtes à intervalle régulier juste pour constater qu'il n'y a rien de neuf. Ça crée du trafic inutile, du parsing supplémentaire et plus de risques de timeout.
Avec le streaming, le serveur garde une connexion ouverte et pousse les nouvelles données seulement quand quelque chose change. Si le statut d'une commande évolue, qu'une métrique franchit un seuil ou qu'un job passe de 40 % à 41 %, la mise à jour peut apparaître immédiatement au lieu d'attendre la prochaine fenêtre de polling.
Cette latence réduite n'est pas seulement une question de vitesse. Elle change la sensation de l'UI. Le polling produit souvent des « sauts » visibles : un spinner apparaît, les données se rafraîchissent par à-coups et les chiffres sautent. Le streaming tend à produire des mises à jour plus petites et fréquentes, ce qui paraît plus fluide et plus fiable.
Le streaming peut aussi rendre le travail serveur plus simple à raisonner. Le polling renvoie souvent une réponse complète à chaque fois, même si 99 % est identique. Avec un flux, vous pouvez n'envoyer que les changements : moins d'octets, moins de lectures répétées en base et moins de sérialisation répétée.
En pratique, le contraste ressemble à ceci : le polling crée de nombreuses courtes requêtes qui retournent souvent « rien de nouveau » ; le streaming utilise une connexion longue et envoie des messages seulement quand nécessaire. La latence du polling dépend de l'intervalle choisi (2 s, 10 s, etc.). La latence du streaming dépend de l'événement lui‑même (mise à jour → l'utilisateur la voit). Les réponses en polling sont souvent des instantanés complets, tandis que les flux peuvent envoyer de petits deltas.
Retour au tableau de tickets en direct : avec un polling toutes les 5 secondes, vous gaspillez des appels en période calme ou vous acceptez que le tableau soit toujours en retard de quelques secondes. Avec le streaming, les périodes calmes restent calmes, et quand un ticket arrive l'UI peut se mettre à jour immédiatement.
Quand on imagine le streaming, on pense souvent à une grosse « connexion live » qui résout tout. En pratique, les équipes utilisent quelques patterns simples, chacun adapté à un type de mise à jour.
C'est le pattern le plus courant : le client ouvre un appel et le serveur envoie des messages au fur et à mesure. Il convient à tout écran où l'on regarde des choses évoluer.
Un tableau ops en direct en est un bon exemple. Plutôt que le navigateur qui demande « y a‑t‑il une nouvelle commande ? » toutes les 2 secondes, le serveur pousse la mise à jour au moment de l'arrivée. Beaucoup d'équipes envoient aussi des messages de heartbeat pour que l'UI affiche « connecté » et détecte plus vite une connexion rompue.
La même idée s'applique aux mises à jour de progression. Si un rapport prend 3 minutes, le serveur peut streamer des jalons (queued, 10 %, 40 %, generating PDF, done) pour que l'utilisateur voie de l'avancement sans spammer le serveur.
Ici le client envoie beaucoup de petits événements efficacement sur un seul appel, et le serveur répond une fois à la fin (ou seulement avec un résumé final). Utile quand vous avez des rafales de données.
Pensez à une appli mobile capturant des relevés capteurs ou à une caisse enregistrant des actions hors ligne. Quand le réseau est disponible, elle peut streamer un lot d'événements avec moins d'overhead que des centaines de requêtes REST séparées.
Pour les conversations continues où les deux côtés peuvent parler à tout moment. Un outil de dispatch peut envoyer des commandes à une app terrain pendant que l'app stream son statut en retour. La collaboration en direct (plusieurs utilisateurs éditant le même enregistrement) peut aussi s'y prêter.
Le request‑response reste le meilleur choix quand le résultat est une seule réponse, que les mises à jour sont rares, ou que vous voulez le chemin le plus simple via caches, gateways et monitoring.
Commencez par écrire ce qui doit vraiment changer à l'écran immédiatement et ce qui peut attendre quelques secondes. La plupart des produits n'ont qu'une petite tranche « chaude » : un compteur live, une barre de progression, un badge de statut.
Séparez les mises à jour en deux catégories : temps réel et « assez bien plus tard ». Par exemple, un dashboard support peut avoir besoin que les nouveaux tickets apparaissent immédiatement, mais les totaux hebdomadaires peuvent se rafraîchir chaque minute sans que personne ne s'en aperçoive.
Ensuite, nommez vos types d'événements et gardez chaque mise à jour petite. N'envoyez pas l'objet entier si un seul champ change. Une approche pratique est de définir des événements comme TicketCreated, TicketStatusChanged, et JobProgressUpdated, chacun avec uniquement les champs dont l'UI a besoin.
Un flux de conception utile :
Le comportement de reconnexion bloque souvent les équipes. Une valeur par défaut solide : à la connexion, envoyer un instantané (état courant), puis les événements incrémentaux. Si vous supportez la reprise, incluez un curseur comme « last event id » pour que le client puisse demander « envoie‑moi tout après 18452 ». Ça rend les reconnexions prévisibles.
Le backpressure, c'est le « que faire si le client n'arrive pas à suivre ? ». Pour un tableau de bord, il est souvent acceptable de fusionner les mises à jour : si la progression passe 41 %, 42 %, 43 % pendant que le téléphone est occupé, envoyez seulement 43 %.
Prévoyez aussi un fallback pour garder le produit utilisable. Choix courants : basculer temporairement vers du polling toutes les 5 à 15 secondes, ou un bouton de rafraîchissement manuel pour les écrans moins critiques.
Si vous construisez dans AppMaster, cela se mappe souvent à deux chemins : un flux piloté par événements pour les mises à jour « chaudes » et une API standard pour l'instantané de secours.
Imaginez un tableau de bord d'entrepôt affichant les niveaux de stock pour 200 SKU. Avec du REST polling, le navigateur pourrait appeler /inventory toutes les 5 secondes, recevoir une liste JSON complète et repeindre le tableau. La plupart du temps, rien n'a changé, mais vous payez quand même : requêtes répétées, réponses complètes répétées, parsing répété.
Avec le streaming, le flux s'inverse. Le client ouvre un stream long. Il reçoit d'abord un instantané initial (pour que l'UI rende immédiatement), puis seulement de petites mises à jour quand quelque chose change.
Une vue de dashboard typique devient :
Ajoutez un second écran : un long job, comme l'import d'un CSV ou la génération de factures mensuelles. Le polling produit souvent des sauts gênants : 0 %, 0 %, 0 %, 80 %, done. Le streaming rend le tout honnête et calme.
Un stream de progression envoie généralement de petits instantanés fréquents :
Choix clé : deltas vs instantanés. Pour l'inventaire, les deltas sont idéaux car ils sont minuscules. Pour la progression d'un job, les instantanés sont souvent plus sûrs car chaque message est déjà petit et cela réduit la confusion si un client se reconnecte et manque un message.
Si vous construisez des applis sur une plateforme comme AppMaster, cela se traduit typiquement par un read model (état initial) plus des mises à jour de type événement (deltas), pour que l'UI reste réactive sans marteler votre API.
Sur téléphone, une « connexion continue » se comporte différemment que sur desktop. Les réseaux basculent entre Wi‑Fi et cellulaire, les tunnels se réinitialisent, et les utilisateurs entrent dans des ascenseurs. Le grand changement : on pense moins en requêtes uniques et plus en sessions qui peuvent disparaître à tout moment.
Préparez‑vous aux déconnexions et concevez pour des relectures sûres. Un bon stream inclut un curseur comme « last event id » pour que l'app puisse se reconnecter et dire « reprends d'ici ». Sans cela, les utilisateurs voient des doublons (la même étape de progression deux fois) ou des manques (sauter de 40 % à 90 %).
La batterie s'améliore souvent avec le streaming parce que l'appli évite des réveils constants pour poller. Mais cela n'est vrai que si les messages sont petits et pertinents. Envoyer des objets entiers chaque seconde est une façon rapide de griller la data et la batterie. Préférez des événements compacts comme « order 183 status changed to Shipped » plutôt que de renvoyer toute la commande.
Quand l'app est en arrière‑plan, le streaming est souvent mis en pause ou tué par l'OS. Prévoyez un fallback clair : afficher le dernier état connu, puis resynchroniser au foreground. Pour les événements urgents, utilisez les notifications push de la plateforme et laissez l'app s'ouvrir et resynchroniser quand l'utilisateur tape.
Approche pratique pour dashboards mobiles et progression :
Si vous construisez des apps mobiles avec AppMaster, traitez le stream comme « pratique quand disponible » et non « source unique de vérité ». L'UI doit rester utilisable pendant de courtes déconnexions.
Le streaming peut sembler une victoire sur le papier, jusqu'à ce que les réseaux réels interviennent. La grosse différence est la connexion : le streaming signifie souvent une connexion HTTP/2 longue, et ça peut contrarier des proxies d'entreprise, des middleboxes et des configurations de sécurité strictes.
Les réseaux d'entreprise utilisent parfois l'inspection TLS (proxy qui décrypte et ré‑chiffre le trafic). Ça peut casser la négociation HTTP/2, bloquer les streams longs, ou rétrograder le comportement de façon silencieuse. Les symptômes : déconnexions aléatoires, streams qui ne démarrent jamais, ou mises à jour arrivant par bursts plutôt que de façon fluide.
Le support HTTP/2 est indispensable pour le gRPC classique. Si un proxy ne parle que HTTP/1.1, les appels peuvent échouer même si le REST normal fonctionne. C'est pourquoi les environnements type navigateur nécessitent souvent gRPC‑Web, conçu pour traverser plus d'infrastructure HTTP courante.
Même quand le réseau permet HTTP/2, l'infrastructure a souvent des timeouts d'inactivité. Un stream qui reste silencieux peut être fermé par un load balancer ou un proxy.
Corrections courantes :
Si des utilisateurs sont derrière des réseaux d'entreprise très verrouillés, traitez le streaming comme best‑effort et fournissez un canal de secours. Une division courante : garder le streaming gRPC pour les apps natives, mais autoriser gRPC‑Web (ou de courts polls REST) quand le réseau se comporte comme un proxy navigateur.
Testez depuis les mêmes lieux que vos utilisateurs :
Si vous déployez avec AppMaster vers AppMaster Cloud ou un grand cloud, validez ces comportements de bout en bout, pas seulement en développement local.
Le plus grand piège est de considérer le streaming par défaut. Le temps réel fait plaisir, mais il peut silencieusement augmenter la charge serveur, l'usage batterie mobile et les tickets support. Commencez par être strict sur les écrans qui ont vraiment besoin d'une mise à jour en quelques secondes et ceux qui peuvent se rafraîchir toutes les 30–60 secondes.
Autre erreur fréquente : envoyer l'objet complet à chaque événement. Un dashboard qui pousse un JSON de 200 KB chaque seconde semblera temps réel jusqu'à la première heure d'affluence. Préférez de petits deltas : « order 4832 status changed to shipped » au lieu de « voici toutes les commandes à nouveau ».
La sécurité est souvent négligée. Avec des streams longs, il faut toujours une authentification et des contrôles d'autorisation robustes, et prévoir l'expiration de token en cours de stream. Si un utilisateur perd l'accès à un projet, le serveur doit cesser d'envoyer immédiatement.
Le comportement de reconnexion casse beaucoup d'apps en conditions réelles, surtout sur mobile. Les téléphones basculent entre Wi‑Fi et LTE, s'endorment et sont backgroundés. Quelques bonnes habitudes : supposer les déconnexions ; reprendre depuis un last‑seen event id (ou un timestamp) ; rendre les mises à jour idempotentes pour que les retries n'entraînent pas de duplications ; configurer timeouts et keepalive clairs pour les réseaux lents ; proposer un mode dégradé (rafraîchissement moins fréquent) quand le streaming échoue.
Enfin, beaucoup d'équipes déploient le streaming sans visibilité. Mesurez taux de déconnexion, boucles de reconnexion, latence des messages et mises à jour perdues. Si votre stream de progression montre 100 % côté serveur mais que les clients restent bloqués à 70 % pendant 20 s, il vous faut des métriques pour localiser le retard (serveur, réseau ou client).
Décidez ce que « temps réel » signifie réellement pour vos utilisateurs.
Commencez par la latence. Si un dashboard doit paraître live, des mises à jour sous 1 seconde peuvent justifier un stream. Si les utilisateurs peuvent attendre 10–60 secondes, le polling gagne souvent en coût et simplicité.
Regardez ensuite le fan‑out. Un flux unique regardé par beaucoup de personnes en même temps (un dashboard ops sur un écran mural + 50 navigateurs) transforme le polling en charge permanente. Le streaming peut réduire les requêtes répétées, mais il faut tout de même gérer de nombreuses connexions ouvertes.
Checklist rapide de décision :
Pensez aussi à l'échec et la récupération. Le streaming est excellent quand il fonctionne, mais le dur est la reconnexion, les événements manqués et la cohérence UI. Une conception pratique : utiliser le streaming pour le fast path, mais définir une action de resync (une requête REST) qui reconstruit l'état courant après la reconnexion.
Si vous prototypez un dashboard rapidement (par exemple avec une UI no‑code dans AppMaster), appliquez cette checklist tôt pour ne pas surconstruire le backend avant de comprendre les besoins de mise à jour.
Traitez le streaming comme quelque chose à mériter, pas comme un interrupteur à basculer. Choisissez un endroit où la fraîcheur vaut clairement le coût, et laissez le reste tel quel jusqu'à avoir des données.
Commencez par un stream de haute valeur : mises à jour de progression d'un long job (import de fichier, génération de rapport) ou une carte d'un tableau live (commandes du jour, tickets actifs, longueur de file actuelle). Garder la portée petite facilite la comparaison avec le polling en chiffres réels.
Plan pilote simple :
Gardez le fallback volontaire. Certains réseaux d'entreprise, anciens proxies ou pare‑feu stricts interfèrent avec HTTP/2, et les réseaux mobiles deviennent instables quand l'app passe en background. Une dégradation gracieuse évite écrans vides et tickets support.
Si vous voulez livrer sans trop de code sur mesure, AppMaster (appmaster.io) peut vous aider à construire la logique backend, les API et l'UI rapidement, puis itérer selon les besoins. Commencez petit, prouvez la valeur, et ajoutez des streams uniquement là où ils surpassent clairement le polling.
21 janv. 2026
8 min
20 janv. 20268 min
20 janv. 20268 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
