gRPC

gRPC ist ein High-Performance-RPC-Framework von Google. Es basiert auf HTTP/2 und verwendet Protocol Buffers als Standard für Serialisierung. gRPC wird häufig für Microservice-Kommunikation eingesetzt.

RPC steht für Remote Procedure Call. Ein Client ruft Methoden auf einem entfernten Server auf, als wären sie lokal. gRPC abstrahiert dabei Netzwerkdetails.

HTTP/2 ermöglicht Multiplexing über eine einzige Verbindung. Es unterstützt Header-Kompression und bidirektionale Streams. Dadurch ist gRPC schneller und effizienter als HTTP/1.1.

Protocol Buffers sind ein binäres Serialisierungsformat. Sie sind kompakt, schnell und sprachunabhängig. Sie dienen als Vertrag zwischen Client und Server.

Eine .proto Datei definiert Services, Methoden und Nachrichtenstrukturen. Sie ist die zentrale Schnittstelle von gRPC. Aus ihr werden Client- und Server-Stubs generiert.

Stubs sind automatisch generierter Code. Sie kapseln die Netzwerkkommunikation. Entwickler rufen Methoden direkt über den Stub auf.

gRPC unterstützt Unary Calls, Server Streaming, Client Streaming und Bidirectional Streaming. Dadurch sind flexible Kommunikationsmuster möglich. Besonders Streams sind ein großer Vorteil.

Ein Unary Call ist ein klassischer Request-Response-Aufruf. Der Client sendet eine Anfrage und erhält eine Antwort. Das ist der häufigste Anwendungsfall.

Beim Server Streaming sendet der Client eine Anfrage. Der Server antwortet mit mehreren Nachrichten. Das eignet sich für große Datenmengen.

Beim Client Streaming sendet der Client mehrere Nachrichten. Der Server antwortet einmal am Ende. Das wird z. B. für Uploads genutzt.

Client und Server senden gleichzeitig Streams. Kommunikation ist asynchron in beide Richtungen. Das eignet sich für Echtzeit-Anwendungen.

Versionierung erfolgt über Schema-Evolution. Felder werden hinzugefügt, nicht entfernt. Alte Felder werden deprecated markiert.

Neue Felder dürfen hinzugefügt werden. Feldnummern dürfen nicht geändert werden. Dadurch bleiben alte Clients funktionsfähig.

gRPC nutzt Status Codes wie OK, NOT_FOUND oder INTERNAL. Fehler werden strukturiert zurückgegeben. Metadaten können zusätzliche Infos enthalten.

Sie beschreiben den Ergebniszustand eines Calls. Sie ähneln HTTP-Statuscodes. Beispiele sind UNAVAILABLE oder PERMISSION_DENIED.

gRPC unterstützt TLS für Transportverschlüsselung. Authentifizierung erfolgt häufig über JWT oder mTLS. Sicherheit ist integraler Bestandteil.

Mutual TLS authentifiziert Client und Server gegenseitig. Beide Seiten besitzen Zertifikate. Es erhöht Sicherheit stark.

Services kommunizieren über gRPC statt REST. Das reduziert Latenz und Overhead. Besonders interne Kommunikation profitiert.

REST ist textbasiert und nutzt JSON. gRPC ist binär und schneller. gRPC eignet sich besser für interne Services.

Browser-Support ist eingeschränkt. Debugging ist schwieriger als bei REST. gRPC ist weniger menschenlesbar.

Browser unterstützen kein echtes HTTP/2-gRPC. gRPC-Web wird verwendet. Ein Proxy übersetzt Anfragen.

gRPC-Web ermöglicht Browser-Zugriff. Es nutzt HTTP/1.1 oder HTTP/2 mit Proxy. Die Features sind eingeschränkt.

Man nutzt generierte Test-Stubs. Tools wie grpcurl helfen beim Testen. Integrationstests sind üblich.

gRPC unterstützt Client-seitiges Load Balancing. Der Client entscheidet über Zielserver. Service Discovery ist wichtig.

Man nutzt horizontale Skalierung. Load Balancer oder Service Mesh helfen. HTTP/2 hält Verbindungen effizient.

Metriken Logs und Traces sind wichtig. Tools wie OpenTelemetry werden genutzt. Debugging ist sonst schwierig.

Bei interner Service-zu-Service-Kommunikation. Wenn Performance entscheidend ist. Besonders bei vielen Requests.

Für öffentliche APIs. Wenn Browser-Kompatibilität wichtig ist. REST ist dort einfacher.

Über Libraries wie grpc-spring-boot-starter. Services werden als Beans definiert. Protobuf generiert den Code.

Ein Gateway übersetzt gRPC zu REST. Es ermöglicht externe Zugriffe. Intern bleibt gRPC bestehen.