Leer wanneer gRPC-streaming of REST-polling de betere keuze is, met duidelijke voorbeelden voor live dashboards en voortgangsupdates, plus opmerkingen over mobiel en firewalls.
Polling betekent dat de client de server steeds opnieuw om updates vraagt, meestal op een timer (elke 1 seconde, 5 seconden, 30 seconden).
Streaming betekent dat de client één verbinding opent en de server updates blijft sturen zodra ze zich voordoen, zonder te wachten op het volgende verzoek.
Dat ene verschil verklaart waarom streaming en polling in een kleine demo vergelijkbaar kunnen lijken, maar in een echt product heel verschillend gedrag laten zien. Bij polling kies je vooraf een compromie: snellere updates betekenen meer verzoeken. Bij streaming houd je een lijn open en stuur je alleen iets wanneer er echt iets verandert.
In de praktijk verschuiven een paar dingen:
Polling is slechts zo vers als het interval dat je koos, terwijl streaming bijna direct aan kan voelen. Polling levert ook veel "niets veranderd"-antwoorden op, wat kosten toevoegt aan beide kanten (verzoeken, headers, auth-checks, parsing). Op mobiel houdt frequent pollen de radio vaker wakker, wat batterij en data kan verbruiken. En omdat polling de staat samplet, kan het snelle veranderingen tussen intervallen missen, terwijl een goed ontworpen stream gebeurtenissen op volgorde kan leveren.
Een simpel voorbeeld is een live operations-dashboard dat nieuwe orders en hun status toont. Pollen elke 10 seconden kan prima zijn op een rustige dag. Maar als het team updates binnen 1 seconde verwacht, voelt polling traag aan of begint het de server te belasten.
Niet elke app heeft real-time nodig. Als gebruikers een pagina af en toe bekijken (zoals maandelijkse rapporten), is pollen elke minuut of verversen op verzoek vaak de eenvoudigste en beste keuze.
Polling voelt rechttoe-rechtaan: de client vraagt steeds "nieuws?" elke N seconden. Het werkt wanneer updates zeldzaam zijn, het aantal gebruikers klein is, of een paar seconden vertraging geen probleem is.
De pijn begint wanneer je frequente actualiteit, veel gebruikers, of beide nodig hebt.
Live dashboards zijn het klassieke geval. Denk aan een ops-scherm met open tickets, betalingsfouten en rode waarschuwingen. Als de cijfers elke paar seconden wijzigen, loopt polling ofwel achter (gebruikers missen pieken) of het slaat je API plat (je servers besteden tijd aan constant antwoorden met "geen verandering").
Voortgangsupdates zijn een andere valkuil. Bestanduploads, rapportgeneratie en videobewerking duren vaak minuten. Elke seconde pollen laat de UI "live" lijken, maar creëert veel extra verzoeken en voelt nog steeds schokkerig omdat de client alleen snapshots ziet.
Onvoorspelbare binnenkomsten maken polling ook inefficiënt. Chat, supportqueues en nieuwe orders kunnen 10 minuten stil zijn en dan 30 seconden exploderen. Met polling betaal je tijdens de stilte en loop je risico op vertragingen tijdens de burst.
IoT-achtige signalen trekken het nog verder. Bij het bijhouden van device online/offline status, last seen en kleine metrics kun je duizenden kleine veranderingen hebben die optellen. Polling verandert dat in een constante stroom van verzoeken.
Polling begint meestal pijn te doen wanneer je patronen ziet zoals: teams verlagen het interval naar 1–2 seconden om responsief te lijken; de meeste responses bevatten geen updates maar verbranden wel headers en auth; de serverload groeit met open tabs in plaats van echte veranderingen; mobiele gebruikers klagen over batterij en data; trafficpieken ontstaan wanneer mensen dashboards openen, niet wanneer business-events plaatsvinden.
De belangrijkste winst van streaming is simpel: je stopt met het steeds opnieuw stellen van dezelfde vraag aan de server wanneer het antwoord meestal "geen verandering" is. Bij polling blijft je app verzoeken sturen op een timer alleen om te ontdekken dat er niets nieuws is. Dat veroorzaakt verspilde verkeer, extra parsing en meer kans op timeouts.
Bij streaming houdt de server één verbinding open en pusht nieuwe data alleen als er iets verandert. Als een orderstatus verandert, een metric een drempel overschrijdt of een achtergrondtaak van 40% naar 41% gaat, kan de update direct verschijnen in plaats van te wachten op het volgende poll-venster.
Die lagere latentie gaat niet alleen over snelheid. Het verandert hoe de UI aanvoelt. Polling produceert vaak zichtbare "sprongen": een spinner verschijnt, data ververst in bursts en cijfers schieten vooruit. Streaming levert meestal kleinere, frequentere updates, wat als vloeiender en betrouwbaarder overkomt.
Streaming kan ook het serverwerk makkelijker maakbaar maken. Polling retourneert vaak een volledige response ieder keer, ook als 99% identiek is. Met een stream kun je alleen de veranderingen sturen, wat minder bytes, minder herhaalde database-leesacties en minder herhaalde serialisatie kan betekenen.
In de praktijk ziet het contrast er zo uit: polling creëert veel korte verzoeken die vaak "niets nieuws" teruggeven; streaming gebruikt één langlevende verbinding en stuurt berichten alleen wanneer nodig. Polling-latentie hangt af van het gekozen interval (2 s, 10 s, enz.). Streaming-latentie hangt samen met het event zelf (update gebeurt, gebruiker ziet het). Polling-responses zijn vaak volledige snapshots, terwijl streams kleine deltas kunnen sturen.
Terug naar het live ticket-dashboard: met pollen elke 5 seconden verspil je calls tijdens rustige periodes of accepteer je dat het dashboard altijd een paar seconden achterloopt. Met streaming zijn rustige periodes echt rustig, en wanneer er een ticket binnenkomt kan de UI meteen updaten.
Als mensen aan streaming denken, stellen ze zich vaak één grote "live-verbinding" voor die magisch alles oplost. In de praktijk gebruiken teams een paar eenvoudige patronen, elk passend bij een ander soort update.
Dit is het meest voorkomende patroon: de client opent één call en de server blijft nieuwe berichten sturen zodra die plaatsvinden. Het past bij elk scherm waar gebruikers veranderingen bekijken.
Een live ops-dashboard is een duidelijk voorbeeld. In plaats van dat de browser vraagt "nieuwe orders elke 2 seconden?" pusht de server een update op het moment dat een nieuwe order binnenkomt. Veel teams sturen ook af en toe heartbeat-berichten zodat de UI "connected" kan tonen en verbroken verbindingen sneller kan detecteren.
Hetzelfde idee geldt voor voortgangsupdates. Als een rapport 3 minuten duurt, kan de server mijlpalen streamen (queued, 10%, 40%, generating PDF, done) zodat de gebruiker beweging ziet zonder de server te spammen.
Hier stuurt de client veel kleine events efficiënt over één call, en de server reageert eenmaal aan het einde (of alleen met een eindsamenvatting). Het is nuttig bij bursts van data.
Denk aan een mobiele app die sensormetingen vastlegt of een POS-app die offline acties buffert. Zodra het netwerk beschikbaar is kan die een batch events streamen met minder overhead dan honderden aparte REST-verzoeken.
Dit is voor lopende gesprekken waarbij beide kanten op elk moment kunnen praten. Een dispatcher-tool kan commando's sturen naar een field-app terwijl de app status terugstreamt. Live samenwerking (meerdere gebruikers die hetzelfde record bewerken) kan hier ook bij passen.
Request-response blijft de beste keuze wanneer het resultaat één antwoord is, updates zeldzaam zijn, of je de eenvoudigste weg door caches, gateways en monitoring wilt.
Begin met opschrijven wat echt direct op het scherm moet veranderen en wat een paar seconden kan wachten. De meeste producten hebben maar een kleine "hot" slice: een live teller, een voortgangsbalk, een statusbadge.
Splits updates in twee bakken: real-time en "goed genoeg later." Bijvoorbeeld: een support-dashboard moet nieuwe tickets onmiddellijk laten verschijnen, maar weektotalen kunnen elke minuut verversen zonder dat iemand het merkt.
Noem daarna je eventtypes en houd elke update klein. Stuurt niet het hele object elke keer als slechts één veld verandert. Een praktische aanpak is events te definiëren zoals TicketCreated, TicketStatusChanged en JobProgressUpdated, elk met alleen de velden die de UI nodig heeft om te reageren.
Een nuttige ontwerpflow:
Reconnect-gedrag is waar veel teams vastlopen. Een solide default is: bij connect stuur een snapshot (huidige staat), daarna incrementiële events. Als je resume ondersteunt, includeer een cursor zoals "last event id" zodat een client kan vragen: "stuur me alles na 18452." Dat houdt reconnects voorspelbaar.
Backpressure is gewoon het "wat als de client het tempo niet bijhoudt?"-probleem. Voor een live dashboard is het vaak prima om updates samen te vouwen. Als voortgang 41%, 42%, 43% beweegt terwijl de telefoon bezig is, kun je alleen 43% sturen.
Plan ook een fallback die het product bruikbaar houdt. Gebruikelijke keuzes zijn tijdelijk overschakelen naar pollen elke 5–15 seconden, of een handmatige refresh-knop voor minder kritische schermen.
Als je bouwt in AppMaster, vertaalt dit zich vaak in twee paden: een event-gedreven flow voor de "hot" updates en een standaard API-leesactie voor de fallback-snapshot.
Stel je een magazijndashboard voor dat voorraadniveaus toont voor 200 SKU's. Met REST-polling zou de browser elke 5 seconden /inventory kunnen aanroepen, een volledige JSON-lijst ontvangen en de tabel herschilderen. Meestal verandert er niets, maar je betaalt toch de kosten: herhaalde verzoeken, volle responses en parsing.
Met streaming keert het stroomdiagram om. De client opent één langlevende stream. Eerst ontvangt die een initiële snapshot (zodat de UI direct kan renderen), daarna alleen kleine updates als er iets verandert.
Een typisch dashboardview wordt:
Voeg nu een tweede scherm toe: een langlopende taak, zoals CSV-import of maandelijkse facturen genereren. Polling levert vaak ongemakkelijke sprongen: 0%, 0%, 0%, 80%, klaar. Streaming maakt het eerlijker en kalmer.
Een voortgangstream stuurt meestal kleine, frequente snapshots:
Een belangrijke ontwerpkeuze is deltas vs snapshots. Voor inventaris zijn deltas geweldig omdat ze kleinschalig zijn. Voor jobprogress zijn snapshots vaak veiliger omdat elk bericht al klein is en het verwarring vermindert als een client reconnect en een bericht mist.
Als je apps bouwt op een platform zoals AppMaster, vertaalt dit zich typisch naar een read-model (initiële staat) plus event-achtige updates (deltas), zodat de UI responsief blijft zonder je API te belasten.
Op een telefoon gedraagt een "continue verbinding" zich anders dan op een desktop. Netwerken schakelen tussen Wi-Fi en mobiel, tunnels resetten en gebruikers lopen in een lift. Het grote verschil is dat je stopt met denken in losse requests en begint te denken in sessies die elk moment kunnen verdwijnen.
Verwacht disconnects en ontwerp voor veilige replays. Een goede stream bevat een cursor zoals "last event id" zodat de app kan reconnecten en zeggen: "hervat vanaf hier." Zonder dat zien gebruikers dubbele updates (dezelfde progress-stap twee keer) of missen ze updates (springen van 40% naar 90%).
Batterij kan vaak verbeteren met streaming omdat de app constante wekkingen om te pollen vermijdt. Dat geldt alleen als berichten klein en betekenisvol zijn. Hele objecten elke seconde sturen is een snelle manier om data en batterij te verbranden. Geef de voorkeur aan compacte events zoals "order 183 status changed to Shipped" in plaats van het hele order-objekt opnieuw te sturen.
Wanneer de app op de achtergrond draait wordt streaming vaak gepauzeerd of door het OS beëindigd. Plan een duidelijke fallback: toon de laatst bekende staat en ververs op foreground. Voor urgente events gebruik platform pushmeldingen en laat de app her-synchroniseren wanneer de gebruiker opent.
Een praktische aanpak voor mobiele dashboards en voortgangsupdates:
Als je mobiele apps bouwt met AppMaster, behandel de stream als "fijn als beschikbaar", niet als "de enige bron van waarheid." De UI moet bruikbaar blijven tijdens korte disconnects.
Streaming kan op papier een duidelijke winst zijn, totdat echte netwerken in beeld komen. Het grote verschil is de verbinding: streaming betekent vaak één langlevende HTTP/2-verbinding, en dat kan corporate proxies, middleboxes en strikte security-setups storen.
Bedrijfsnetwerken gebruiken soms TLS-inspectie (een proxy die het verkeer decrypt en opnieuw encrypt). Dat kan HTTP/2-negotiation breken, lange streams blokkeren of het gedrag stilletjes downgraden op manieren die moeilijk te detecteren zijn. Symptomen zijn willekeurige disconnects, streams die nooit starten of updates die in bursts in plaats van vloeiend aankomen.
HTTP/2-ondersteuning is ononderhandelbaar voor klassieke gRPC. Als een proxy alleen HTTP/1.1 spreekt, kunnen calls falen hoewel gewone REST gewoon werkt. Daarom hebben browser-achtige omgevingen vaak gRPC-Web nodig, dat is ontworpen om door meer voorkomende HTTP-infrastructuur te komen.
Zelfs wanneer het netwerk HTTP/2 toelaat, heeft infrastructuur vaak idle timeouts. Een stream die een tijdje stil blijft kan door een load balancer of proxy gesloten worden.
Veelvoorkomende oplossingen:
Als gebruikers achter streng afgeschermde bedrijfsnetwerken zitten, behandel streaming als best-effort en voorzie een fallback-kanaal. Een gangbare splitsing is streaming voor native apps te houden, maar gRPC-Web (of korte REST-polls) toe te staan wanneer het netwerk zich gedraagt als een browserproxy.
Test vanuit dezelfde plekken waar je gebruikers werken:
Als je deployt met AppMaster naar AppMaster Cloud of een grote cloudprovider, valideer deze gedragingen end-to-end, niet alleen in lokale ontwikkeling.
De grootste valkuil is streaming als default behandelen. Real-time voelt goed, maar kan stilletjes serverload, mobiel batterijverbruik en supporttickets verhogen. Begin strikt met welke schermen echt updates binnen seconden nodig hebben en welke elke 30–60 seconden mogen verversen.
Een andere veelgemaakte fout is bij elk event het volledige object sturen. Een live dashboard dat een 200 KB JSON-bundel elke seconde pusht voelt real-time totdat het eerste drukke uur komt. Geef de voorkeur aan kleine deltas: "order 4832 status changed to shipped" in plaats van "hier zijn alle orders opnieuw."
Security wordt vaker gemist dan teams toegeven. Bij langlevende streams heb je nog steeds sterke authenticatie- en autorisatiechecks nodig en moet je plannen voor tokenverloop midden in de stream. Als een gebruiker geen toegang meer heeft tot een project, moet de server direct stoppen met sturen.
Reconnect-gedrag is waar veel apps in de echte wereld breken, vooral op mobiel. Telefoons schakelen tussen Wi-Fi en LTE, gaan slapen en worden gebackgrounded. Een paar gewoonten voorkomen de ergste fouten: neem disconnects aan; hervat vanaf een last-seen event id (of timestamp); maak updates idempotent zodat retries geen dubbele acties veroorzaken; stel duidelijke timeouts en keepalive-settings in voor trage netwerken; bied een gedegradeerde fallbackmodus (minder frequent verversen) wanneer streaming faalt.
Tot slot sturen teams streaming uit zonder zichtbaarheid. Meet disconnect-rate, reconnect-loops, message-lag en gedropte updates. Als je jobprogress-stream op de server 100% toont maar clients steken op 70% voor 20 seconden, heb je metrics nodig die laten zien waar de vertraging zit (server, netwerk of client).
Bepaal wat "real-time" daadwerkelijk betekent voor je gebruikers.
Begin met latentie. Als een dashboard live moet aanvoelen, kunnen updates onder 1 seconde een stream rechtvaardigen. Als gebruikers alleen elke 10–60 seconden moeten verversen, wint simpel pollen vaak op kosten en eenvoud.
Kijk dan naar fan-out. Een enkele datafeed die door veel mensen tegelijk bekeken wordt (een ops-dashboard op een wallscreen plus 50 browsers) kan polling veranderen in constante achtergrondload. Streaming kan herhaalde verzoeken verminderen, maar je moet nog steeds veel open verbindingen afhandelen.
Een snelle beslis-checklist:
Denk ook na over falen en herstel. Streaming is geweldig als het werkt, maar het moeilijke deel zijn reconnects, gemiste events en het consistent houden van de UI. Een praktische aanpak is streaming voor het snelle pad te gebruiken, maar een resync-actie (één REST-call) definiëren die de huidige staat opnieuw opbouwt na reconnect.
Als je snel een dashboard prototypet (bijv. met een no-code UI in AppMaster), kun je deze checklist vroeg toepassen zodat je de backend niet overbouwt voordat je de updatebehoeften begrijpt.
Behandel streaming als iets dat je verdient, niet als een schakel die je omdraait. Kies één plek waar actualiteit duidelijk de moeite waard is en laat alles anders zoals het is totdat je data hebt.
Begin met één high-value stream, zoals jobprogress voor een lange taak (bestandimport, rapportgeneratie) of één kaart op een live dashboard (vandaag's orders, actieve tickets, huidige wachtrijlengte). Een beperkte scope maakt het ook makkelijker om te vergelijken met pollen op basis van echte cijfers.
Een simpel pilotplan:
Houd de fallback doelbewust. Sommige bedrijfsnetwerken, oudere proxies of strikte firewalls verstoren HTTP/2, en mobiele netwerken worden onstabiel als de app backgrounded raakt. Een gracieuze downgrade voorkomt lege schermen en supporttickets.
Als je dit zonder veel custom code wilt uitrollen, kan AppMaster (appmaster.io) je helpen backendlogica, API's en UI snel te bouwen en dan itereren als de eisen veranderen. Begin klein, bewijs de waarde en voeg streams alleen toe waar ze duidelijk beter zijn dan pollen.
21 jan 2026
8 min
20 jan 20268 min
20 jan 20267 minExperimenteer met AppMaster met gratis abonnement.
Als je er klaar voor bent, kun je het juiste abonnement kiezen.
