gRPC-Grundlagen: Protobuf-Verträge, Streaming und Einsatzbereich

Worum es geht

Die zitierte gRPC-Einführung beschreibt das Modell: Ein Dienst und seine Methoden werden in einer .proto-Datei definiert, protoc generiert Client-Stubs und Server-Schnittstellen je Sprache, und ein Client ruft eine Methode auf einem entfernten Server auf, als wäre sie ein lokales Objekt; Protocol Buffers dienen standardmässig sowohl als Interface Definition Language als auch als Nachrichtenformat. Die zitierte Seite zu den Kernkonzepten nennt vier Arten von Methoden: unär, Server-Streaming, Client-Streaming und bidirektionales Streaming. Jeder Aufruf kann eine Deadline tragen, nach deren Ablauf er mit DEADLINE_EXCEEDED fehlschlägt; jede Seite kann abbrechen; Metadaten reisen als Schlüssel-Wert-Paare neben dem Aufruf; und Aufrufe enden mit einem Status aus einer festen Menge (OK, NOT_FOUND, UNAVAILABLE und andere). Die zitierte FAQ hält fest, dass gRPC der HTTP-Semantik über HTTP/2 folgt, dabei aber explizit Full-Duplex-Streaming erlaubt, statische Pfade zur Zustellung verwendet und eine eigene Fehlermenge statt HTTP-Statuscodes formalisiert.

Warum es wichtig ist

Generierte, typisierte Clients in vielen Sprachen sowie Streaming und Deadlines, die sich durch Aufrufketten fortpflanzen, beseitigen eine ganze Klasse von handgeschriebenem Client-Code und Timeout-Fehlern. Der Preis dafür sind binäre Payloads, HTTP/2 durchgängig und Tooling, das gewöhnliches curl nicht mitbringt.

So wird es angewendet

• gRPC für interne Service-zu-Service-Aufrufe einsetzen, bei denen beide Enden aus denselben .proto-Dateien generiert werden, für Streams (Telemetrie, Abonnements, grosse Ergebnismengen) und für mobile Clients, wo die FAQ Einsparungen bei Bandbreite und Verbindungen nennt.
• Bei jedem Client-Aufruf eine Deadline setzen und die verbleibende Deadline an nachgelagerte Aufrufe weitergeben; Server in langen Schleifen auf Abbruch prüfen lassen.
• Fehler auf die Standard-Statuscodes abbilden und Details in die Meldung oder die Error-Details legen; keine eigenen Codes erfinden.
• .proto-Dateien in einem Paket mit Kompatibilitätsprüfung bei Änderungen halten; Feldnummern sind der Vertrag.
• Für Browser gRPC-Web verwenden, das die FAQ als generell verfügbar beschreibt; für öffentliche Partner-APIs JSON über HTTP anbieten, entweder anstelle der gRPC-Definitionen oder aus ihnen transcodiert.
• Sicherstellen, dass jeder Load Balancer und Proxy im Pfad HTTP/2 bis zum Backend durchreicht; gRPC benötigt es durchgängig.

Stolpersteine

Anzunehmen, gRPC sei automatisch schnell: Serialisierung ist günstig, aber ein geschwätziges Design bleibt geschwätzig. Langlebige Streams, die eine Verbindung an ein Backend binden und Lastverteilung aushebeln. INVALID_ARGUMENT wie UNAVAILABLE erneut versuchen, weil der Client nicht zwischen wiederholbaren Codes unterscheidet. gRPC gegenüber Integratoren offenlegen, die nur HTTP-Tooling besitzen.