Erfahren Sie, wann gRPC-Streaming gegenüber REST-Polling sinnvoller ist — mit Beispielen für Live-Dashboards, Fortschritts-Updates sowie Hinweisen zu Mobilgeräten und Firewalls.
Polling bedeutet, dass der Client den Server immer wieder nach Updates fragt, normalerweise in regelmäßigen Abständen (jede Sekunde, alle 5 Sekunden, alle 30 Sekunden).
Streaming bedeutet, dass der Client eine Verbindung öffnet und der Server fortlaufend Updates schickt, sobald sie passieren — ohne auf die nächste Anfrage zu warten.
Dieser eine Unterschied erklärt, warum Streaming und Polling in einer kleinen Demo ähnlich wirken können, aber in einem echten Produkt sehr unterschiedlich laufen. Beim Polling wählt man einen Kompromiss im Voraus: schnellere Updates bedeuten mehr Anfragen. Beim Streaming hält man eine Leitung offen und sendet nur, wenn sich tatsächlich etwas ändert.
In der Praxis verschieben sich dadurch ein paar Dinge:
Polling ist nur so aktuell wie das gewählte Intervall, während Streaming nahezu sofort wirken kann. Polling erzeugt außerdem viele „keine Änderung“-Antworten, was auf beiden Seiten Kosten verursacht (Anfragen, Header, Auth-Prüfungen, Parsing). Auf Mobilgeräten hält häufiges Polling das Funkmodul öfter wach und kann Akku und Datenverbrauch erhöhen. Und weil Polling den Zustand nur stichprobenartig erfasst, kann es schnelle Änderungen zwischen den Intervallen verpassen, während ein gut gestalteter Stream Ereignisse in Reihenfolge liefern kann.
Ein einfaches Beispiel ist ein Live-Ops-Dashboard, das neue Bestellungen und ihren Status zeigt. Polling alle 10 Sekunden reicht an einem ruhigen Tag vielleicht aus. Wenn das Team aber Updates innerhalb von einer Sekunde erwartet, wirkt Polling träge oder beginnt, den Server zu überlasten.
Nicht jede App braucht Echtzeit. Wenn Nutzer eine Seite nur gelegentlich prüfen (z. B. Monatsberichte), sind Polling alle Minute oder manuelles Aktualisieren oft die einfachste und beste Wahl.
Polling wirkt einfach: der Client fragt alle N Sekunden „gibt es etwas Neues?“. Es funktioniert, wenn Updates selten sind, die Nutzerzahl klein ist oder ein paar Sekunden Verzögerung in Ordnung sind.
Schmerzhaft wird es, wenn Sie häufige Aktualität, viele Nutzer oder beides brauchen.
Live-Dashboards sind der klassische Fall. Denken Sie an ein Ops-Screen mit offenen Tickets, Zahlungsfehlern und roten Alerts. Wenn sich die Zahlen alle paar Sekunden ändern, ist Polling entweder träge (Nutzer verpassen Spitzen) oder es bombardiert Ihre API (Server beantworten immer wieder „keine Änderung").
Fortschritts-Updates sind eine weitere Falle. Datei-Uploads, Report-Generierung oder Videoverarbeitung laufen oft Minuten. Polling jede Sekunde lässt die UI „live“ wirken, erzeugt aber viele zusätzliche Anfragen und wirkt trotzdem holprig, weil der Client nur Schnappschüsse sieht.
Unvorhersehbare Ereignisse machen Polling ebenfalls verschwenderisch. Chat, Support-Queues und neue Bestellungen können 10 Minuten still sein und dann 30 Sekunden lang aufkommen. Beim Polling zahlt man in der ruhigen Zeit den Preis und riskiert trotzdem Verzögerungen während des Bursts.
IoT-ähnliche Signale verstärken das Problem. Wenn Sie Geräte-Online/Offline-Status, Last-Seen und kleine Metriken verfolgen, summieren sich tausende kleine Änderungen. Polling multipliziert das zu einem konstanten Strom an Anfragen.
Polling fängt normalerweise an, weh zu tun, wenn Sie Muster sehen wie: Teams verkürzen das Intervall auf 1–2 Sekunden, nur um reaktionsschnell zu wirken; die meisten Antworten enthalten keine Updates, verbrauchen aber Header und Auth; Serverlast wächst mit offenen Tabs statt mit echten Änderungen; Mobile-Nutzer klagen über Akku und Daten; Traffic-Spitzen treten auf, wenn Leute Dashboards öffnen, nicht wenn Geschäftsvorfälle passieren.
Der Hauptvorteil von Streaming ist einfach: Sie hören auf, dem Server immer wieder dieselbe Frage zu stellen, wenn die Antwort meistens „keine Änderung" ist. Beim Polling sendet Ihre App regelmäßig Anfragen, nur um festzustellen, dass nichts Neues geschah. Das erzeugt unnötigen Traffic, zusätzliches Parsing und mehr Chancen auf Timeouts.
Beim Streaming hält der Server eine Verbindung offen und pusht nur dann Daten, wenn sich etwas ändert. Wenn sich der Bestellstatus ändert, eine Metrik eine Schwelle überquert oder ein Hintergrundjob von 40% auf 41% springt, kann das Update sofort erscheinen, statt auf das nächste Polling-Fenster zu warten.
Geringere Latenz betrifft nicht nur die Geschwindigkeit. Sie verändert, wie die UI sich anfühlt. Polling erzeugt oft sichtbare „Sprünge“: ein Spinner erscheint, Daten werden in Blöcken aktualisiert und Zahlen springen vor. Streaming liefert tendenziell kleinere, häufigere Updates, was glatt und vertrauenswürdiger wirkt.
Streaming kann auch die Serverarbeit leichter verständlich machen. Polling liefert oft bei jeder Anfrage eine vollständige Antwort, selbst wenn 99% identisch sind. Mit einem Stream können Sie nur die Änderungen senden, was weniger Bytes, weniger wiederholte Datenbankabfragen und weniger wiederholte Serialisierung bedeuten kann.
In der Praxis sieht der Unterschied so aus: Polling erzeugt viele kurze Anfragen, die oft „nichts Neues“ zurückliefern; Streaming nutzt eine längere Verbindung und sendet Nachrichten nur bei Bedarf. Die Polling-Latenz ist an das gewählte Intervall gebunden (z. B. 2 s, 10 s). Die Streaming-Latenz hängt vom Ereignis ab (Update passiert, Nutzer sieht es). Polling-Antworten sind oft vollständige Snapshots, während Streams kleine Deltas senden können.
Beim Live-Ticket-Dashboard gilt: Bei 5-Sekunden-Polling verschwenden Sie Anfragen in ruhigen Perioden oder akzeptieren, dass das Dashboard immer ein paar Sekunden hinterherhinkt. Mit Streaming sind ruhige Phasen wirklich ruhig, und bei einem neuen Ticket aktualisiert die UI sofort.
Wenn Leute an Streaming denken, stellen sie sich oft eine große „Live-Verbindung“ vor, die alles magisch löst. In der Realität nutzen Teams ein paar einfache Muster, die zu verschiedenen Update-Arten passen.
Das ist das gebräuchlichste Muster: Der Client öffnet eine Verbindung und der Server sendet fortlaufend neue Nachrichten. Es passt zu Bildschirmen, in denen Nutzer Dinge beobachten, die sich ändern.
Ein Live-Ops-Dashboard ist ein klares Beispiel. Anstatt dass der Browser alle 2 Sekunden fragt „gibt es neue Bestellungen?“, pusht der Server ein Update, sobald eine neue Bestellung reinkommt. Viele Teams senden auch gelegentliche Heartbeats, damit die UI „verbunden“ anzeigen und ausgefallene Verbindungen schneller erkennen kann.
Dasselbe gilt für Fortschritts-Updates. Dauert ein Report 3 Minuten, kann der Server Meilensteine streamen (queued, 10%, 40%, generating PDF, done), sodass der Nutzer Bewegung sieht, ohne den Server zu spammen.
Hier sendet der Client viele kleine Ereignisse effizient über eine Verbindung, und der Server antwortet am Ende einmal (oder nur mit einer Zusammenfassung). Das ist nützlich bei Daten-Bursts.
Denken Sie an eine Mobile-App, die Sensordaten erfasst, oder eine POS-App, die Offline-Aktionen puffert. Sobald das Netzwerk verfügbar ist, kann sie ein Batch streamen und so Overhead vermeiden, der bei hunderten separaten REST-Requests entstehen würde.
Das ist für fortlaufende Gespräche, bei denen beide Seiten jederzeit sprechen können. Ein Dispatcher-Tool kann Befehle an eine Feld-App senden, während die App Status zurückstreamt. Live-Collaboration (mehrere Nutzer, die denselben Datensatz bearbeiten) passt ebenfalls.
Request-Response bleibt die beste Wahl, wenn das Ergebnis eine einzelne Antwort ist, Updates selten sind oder Sie den einfachsten Weg durch Caches, Gateways und Monitoring brauchen.
Beginnen Sie damit aufzuschreiben, was auf dem Bildschirm wirklich sofort ändern muss und was ein paar Sekunden warten kann. Die meisten Produkte haben nur einen kleinen „heißen“ Bereich: ein Live-Zählwerk, eine Fortschrittsanzeige, ein Status-Badge.
Teilen Sie Updates in zwei Kategorien auf: Echtzeit und „später ist gut genug“. Zum Beispiel: Ein Support-Dashboard muss neue Tickets sofort zeigen, aber wöchentliche Gesamtsummen können jede Minute aktualisiert werden, ohne dass es jemand merkt.
Benennen Sie dann Ihre Ereignistypen und halten Sie jede Aktualisierung klein. Senden Sie nicht das ganze Objekt, wenn sich nur ein Feld ändert. Eine praktische Herangehensweise ist, Ereignisse wie TicketCreated, TicketStatusChanged und JobProgressUpdated zu definieren — jeweils nur mit den Feldern, die die UI braucht.
Ein nützlicher Designablauf:
Reconnect-Verhalten bringt viele Teams ins Stocken. Eine solide Default-Strategie ist: Beim Verbinden einen Snapshot senden (aktueller Zustand) und dann inkrementelle Ereignisse. Unterstützen Sie Resume mit einem Cursor wie „last event id“, damit ein Client sagen kann: „sende mir alles nach 18452." Das macht Reconnects vorhersehbar.
Backpressure ist das Problem „was, wenn der Client nicht nachkommt?" Für ein Live-Dashboard reicht es oft, Updates zusammenzufassen. Bewegt sich der Fortschritt von 41% auf 42% auf 43% während das Telefon beschäftigt ist, reicht es, nur 43% zu senden.
Planen Sie außerdem einen Fallback, der das Produkt brauchbar hält. Übliche Optionen sind ein temporärer Wechsel zu Polling alle 5–15 Sekunden oder ein manueller Refresh-Button für weniger kritische Bildschirme.
Wenn Sie in AppMaster bauen, lässt sich das oft in zwei Pfade abbilden: ein ereignisgesteuerter Flow für die „heißen“ Updates und ein normaler API-Read für den Fallback-Snapshot.
Stellen Sie sich ein Lager-Dashboard vor, das Bestände für 200 SKUs zeigt. Mit REST-Polling ruft der Browser vielleicht alle 5 Sekunden /inventory auf, erhält eine vollständige JSON-Liste und rendert die Tabelle neu. Meistens ändert sich nichts, aber Sie zahlen trotzdem den Preis: wiederholte Anfragen, volle Antworten und Parsing.
Beim Streaming dreht sich der Ablauf um. Der Client öffnet einen langlebigen Stream. Zuerst erhält er einen initialen Snapshot (damit die UI sofort rendern kann) und danach nur kleine Updates, wenn sich etwas ändert.
Eine typische Dashboard-Ansicht wird dann:
Fügen Sie einen zweiten Bildschirm hinzu: einen lang laufenden Job wie CSV-Import oder Monatsrechnungen. Polling erzeugt oft holprige Sprünge: 0%, 0%, 0%, 80%, fertig. Streaming wirkt ehrlich und ruhig.
Ein Fortschritts-Stream sendet typischerweise kleine, häufige Schnappschüsse:
Eine wichtige Designentscheidung ist Deltas vs Snapshots. Für Inventory sind Deltas großartig, weil sie winzig sind. Für Job-Fortschritt sind Snapshots oft sicherer, weil jede Nachricht sowieso klein ist und es Verwirrung reduziert, wenn ein Client reconnectt und eine Nachricht verpasst.
Wenn Sie in Plattformen wie AppMaster bauen, bildet sich das typischerweise als Read-Model (Initialzustand) plus ereignisartige Updates (Deltas) ab, sodass die UI responsiv bleibt, ohne Ihre API zu belasten.
Auf dem Telefon verhält sich eine „kontinuierliche Verbindung“ anders als auf dem Desktop. Netzwerke wechseln zwischen WLAN und Mobilfunk, Tunnel setzen zurück und Nutzer gehen in Aufzüge. Der große Unterschied ist, dass Sie nicht mehr in einzelnen Anfragen denken, sondern in Sessions, die jederzeit verschwinden können.
Erwarten Sie Disconnects und designen Sie für sicheres Replay. Ein guter Stream enthält einen Cursor wie „last event id“, damit die App reconnecten und sagen kann: „resume from here." Ohne das sehen Nutzer doppelte Updates (derselbe Fortschrittsschritt zweimal) oder fehlende Updates (Sprung von 40% auf 90%).
Der Akkuverbrauch verbessert sich oft mit Streaming, weil die App ständige Weckereignisse zum Polling vermeidet. Das gilt aber nur, wenn Nachrichten klein und sinnvoll sind. Ganze Objekte jede Sekunde zu senden ist ein schneller Weg, Akku und Daten zu verbrennen. Bevorzugen Sie kompakte Ereignisse wie „order 183 status changed to Shipped" statt die gesamte Bestellung erneut zu senden.
Wenn die App im Hintergrund ist, wird Streaming oft vom OS pausiert oder beendet. Planen Sie einen klaren Fallback: letzten bekannten Zustand anzeigen und beim Vordergrund-Start neu synchronisieren. Für dringende Ereignisse nutzen Sie Plattform-Push-Benachrichtigungen und lassen die App beim Tippen neu synchronisieren.
Praktische Ansätze für mobile Dashboards und Fortschritts-Updates:
Wenn Sie Mobile-Apps mit AppMaster bauen, betrachten Sie den Stream als „nette Ergänzung, wenn verfügbar“, nicht als „die einzige Quelle der Wahrheit". Die UI sollte bei kurzen Disconnects weiter nutzbar bleiben.
Streaming sieht auf dem Papier oft wie ein klarer Vorteil aus — bis echte Netzwerke dazwischenkommen. Der große Unterschied ist die Verbindung: Streaming bedeutet häufig eine lange HTTP/2-Verbindung, und das kann Firmenproxies, Middleboxes und strikte Sicherheits-Setups stören.
Firmenetzwerke nutzen manchmal TLS-Inspection (ein Proxy, der den Traffic entschlüsselt und neu verschlüsselt). Das kann HTTP/2-Negotiation brechen, lang laufende Streams blockieren oder Verhalten still downgraden. Symptome sind zufällige Disconnects, Streams, die nie starten, oder Updates, die nicht flüssig, sondern in Batches ankommen.
HTTP/2-Unterstützung ist bei klassischem gRPC unverzichtbar. Wenn ein Proxy nur HTTP/1.1 spricht, können Aufrufe fehlschlagen, obwohl normales REST funktioniert. Deshalb brauchen browserartige Umgebungen oft gRPC-Web, das dafür entwickelt wurde, durch gängigere HTTP-Infrastruktur zu laufen.
Selbst wenn das Netzwerk HTTP/2 zulässt, hat die Infrastruktur oft Idle-Timeouts. Ein Stream, der längere Zeit still bleibt, kann von einem Load Balancer oder Proxy geschlossen werden.
Gängige Lösungen:
Wenn Nutzer hinter stark gesperrten Firmennetzwerken sitzen, betrachten Sie Streaming als Best-Effort und bieten Sie einen Fallback-Kanal an. Eine übliche Aufteilung ist: gRPC-Streaming für native Apps behalten, aber gRPC-Web (oder kurzes REST-Polling) zulassen, wenn das Netzwerk wie ein Browser-Proxy auftritt.
Testen Sie von den Orten aus, an denen Ihre Nutzer arbeiten:
Wenn Sie mit AppMaster in AppMaster Cloud oder bei einem großen Cloud-Anbieter deployen, validieren Sie dieses Verhalten end-to-end, nicht nur in der lokalen Entwicklung.
Die größte Falle ist, Streaming als Default zu behandeln. Echtzeit fühlt sich gut an, kann aber still und heimlich Serverlast, mobilen Akkuverbrauch und Supporttickets erhöhen. Seien Sie strikt darin, welche Bildschirme wirklich Updates innerhalb von Sekunden brauchen und welche alle 30–60 Sekunden aktualisiert werden können.
Ein weiterer häufiger Fehler ist, bei jedem Ereignis das ganze Objekt zu senden. Ein Live-Dashboard, das jeden zweiten eine 200 KB JSON-Blase sendet, fühlt sich bis zur ersten geschäftigen Stunde echt an — und dann bricht es zusammen. Bevorzugen Sie kleine Deltas: „order 4832 status changed to shipped" statt „hier sind alle Bestellungen nochmal".
Sicherheit wird häufiger übersehen, als Teams zugeben. Bei lang laufenden Streams brauchen Sie trotzdem starke Auth- und Authz-Prüfungen und müssen Token-Expiry mitten im Stream planen. Wenn ein Nutzer keinen Zugriff mehr auf ein Projekt hat, sollte der Server sofort aufhören, Updates zu senden.
Reconnect-Verhalten bringt viele Apps in der realen Welt zum Scheitern, besonders auf Mobilgeräten. Telefone wechseln zwischen WLAN und LTE, schlafen ein und werden backgrounded. Ein paar Gewohnheiten verhindern die schlimmsten Fehler: Disconnects annehmen; von einer last-seen event id (oder Zeitstempel) resume ermöglichen; Updates idempotent gestalten, damit Retries nichts duplizieren; klare Timeouts und Keepalive-Einstellungen für langsame Netze setzen; einen degradierten Fallback-Modus anbieten, wenn Streaming fehlschlägt.
Schließlich liefern Teams Streaming ohne Sichtbarkeit. Messen Sie Disconnect-Rate, Reconnect-Loops, Message-Lag und verlorene Updates. Wenn Ihr Job-Progress-Stream auf dem Server 100% anzeigt, aber Clients bei 70% für 20 Sekunden hängen bleiben, brauchen Sie Metriken, die zeigen, wo die Verzögerung entsteht (Server, Netzwerk oder Client).
Definieren Sie, was „Echtzeit" für Ihre Nutzer wirklich bedeutet.
Starten Sie mit der Latenz. Wenn ein Dashboard „live" wirken muss, rechtfertigen Updates unter 1 Sekunde oft einen Stream. Wenn Nutzer alle 10–60 Sekunden zufrieden sind, gewinnt schlichtes Polling in Kosten und Einfachheit.
Betrachten Sie dann Fan-out. Ein einzelner Datenfeed, den viele Leute gleichzeitig beobachten (ein Ops-Dashboard auf einer Wand plus 50 Browser), kann Polling in konstanten Hintergrund-Load verwandeln. Streaming kann wiederholte Anfragen reduzieren, aber Sie müssen trotzdem viele offene Verbindungen handhaben.
Eine schnelle Entscheidungs-Checkliste:
Denken Sie auch an Fehler und Wiederherstellung. Streaming ist toll, wenn es funktioniert, aber die Schwierigkeit liegt in Reconnects, verpassten Events und konsistenter UI. Ein pragmatisches Design ist: Streaming für den schnellen Pfad nutzen, aber eine Resync-Aktion (ein REST-Call) definieren, die nach einem Reconnect den aktuellen Zustand wieder aufbaut.
Wenn Sie schnell ein Dashboard prototypen (z. B. mit einer No-Code-UI in AppMaster), wenden Sie diese Checkliste früh an, damit Sie das Backend nicht überbauen, bevor Sie die Update-Bedürfnisse verstehen.
Behandeln Sie Streaming wie etwas, das man sich verdient, nicht wie einen Schalter, den man umlegt. Wählen Sie einen Bereich, in dem Frische klar ihren Wert hat, und lassen Sie alles andere unverändert, bis Sie Daten haben.
Starten Sie mit einem kleinen, wichtigen Stream, z. B. Job-Fortschritts-Updates für eine lange Aufgabe (Datei-Import, Report-Generierung) oder eine Karte auf einem Live-Dashboard (heutige Bestellungen, aktive Tickets, aktuelle Warteschlangenlänge). Kleine Reichweite erleichtert den Vergleich gegen Polling mit echten Zahlen.
Ein einfacher Pilot-Plan:
Behalten Sie den Fallback bewusst bei. Manche Firmennetze, ältere Proxies oder strikte Firewalls stören HTTP/2; mobile Netze werden instabil, wenn die App backgrounded wird. Ein sanftes Downgrade vermeidet leere Bildschirme und Supporttickets.
Wenn Sie das ohne viel Eigenentwicklung ausliefern wollen, kann AppMaster (appmaster.io) Ihnen helfen, Backend-Logik, APIs und UI schnell zu bauen und dann iterativ anzupassen. Starten Sie klein, beweisen Sie den Wert und fügen Sie Streams nur dort hinzu, wo sie Polling klar schlagen.
21. Jan. 2026
8 Min
20. Jan. 20268 Min
20. Jan. 20268 MinExperimentieren Sie mit AppMaster mit kostenlosem Plan.
Wenn Sie fertig sind, können Sie das richtige Abonnement auswählen.
