gRPC (Google Remote Procedure Call) ist ein leistungsfähiges RPC-Framework, das Google 2015 als Open Source veröffentlichte und heute von der Cloud Native Computing Foundation (CNCF) gepflegt wird. Es bringt Remote Procedure Calls in die Moderne: Statt wie bei REST einzelne Ressourcen über HTTP-Verben anzusprechen, ruft ein Client eine Methode auf einem entfernten Server auf, als wäre es ein lokaler Funktionsaufruf. Typische Einsatzgebiete sind die Kommunikation zwischen Mikroservices, in denen viele kleine Dienste eng verzahnt zusammenarbeiten.

Protokoll-Puffer als Sprache der Dienste

Das Herzstück von gRPC ist JSONs effizientere Alternative: Protocol Buffers (kurz Protobuf). In einer .proto-Datei definiert man die Nachrichtenstruktur und den Service-Vertrag, aus dem der Compiler protoc Client- und Server-Code in vielen Sprachen erzeugt (C++, Go, Java, Python, C#, Rust und weitere). Die binäre Serialisierung ist deutlich kompakter und schneller als textbasiertes JSON und die Typen sind strikt festgelegt – eine Änderung am Vertrag fällt beim Kompilieren auf, nicht erst zur Laufzeit.

Vier Kommunikations-Modelle

  • Unary Call: Client sendet eine Anfrage, Server antwortet einmal (klassisches Request-Response).
  • Server Streaming: Der Client sendet eine Anfrage und empfängt einen kontinuierlichen Datenstrom.
  • Client Streaming: Der Client sendet viele Nachrichten, der Server antwortet am Ende einmal.
  • Bidirektionales Streaming: Beide Seiten senden gleichzeitig über eine einzige Verbindung.

Vorteile durch HTTP/2

Als Transport nutzt gRPC HTTP/2-Features: Multiplexing mehrerer Aufrufe über eine Verbindung, binäre Frames, Komprimierung der Header und Flusskontrolle. Damit erreicht es niedrige Latenzen bei hohem Durchsatz, ideal für latenzkritische Dienste im Rechenzentrum.

gRPC, REST und Streaming im Vergleich

Gegenüber REST bietet gRPC starke Typisierung, native Streaming-Unterstützung und höhere Effizienz – dafür ist es für Browser-Anwendungen weniger geeignet und schwerer zu debuggen als lesbares JSON. Wo ein Server Daten kontinuierlich an viele Clients ausliefert, ist im Browser Server-Sent Events oft die einfachere Wahl; für den Echtzeit-Austausch in beide Richtungen gibt es WebSockets. Für klassische Push-Szenarien mit vorhandener HTTP-Infrastruktur bleibt Long Polling eine pragmatische Option.

Verwandte Grundlagen: API, Mikroservice, Protobuf-Befehle, Service Mesh.