GRPC, Protobuf und Connect#

Als Entwickler bin ich immer auf der Suche nach effizienten und zuverlässigen Technologien, die meine Arbeit verbessern und vereinfachen. In den letzten Jahren habe ich GRPC in zahlreichen Projekten eingesetzt und bin nach wie vor begeistert von den Vorteilen, die es bietet. Aber nicht nur weil es schnell und effizient ist - sondern weil es menschliche Absprachen und Teamarbeit einfacher macht. Wie funktioniert das und warum “Connect” noch mit reinspielt:

Was ist GRPC?#

GRPC (gRPC Remote Procedure Call) ist ein modernes, leistungsstarkes Framework für Remote Procedure Calls (RPC), das von Google entwickelt wurde. Es ermöglicht es Anwendungen, Methoden auf entfernten Systemen so aufzurufen, als wären sie lokale Funktionen. GRPC nutzt HTTP/2 für den Transport und Protocol Buffers (Protobuf) als Serialisierungsformat. Mit anderen Worten: Binäre Batzen per UDP. Klingt schlimm - ist es aber gar nicht: Ich nehm euch mit!

Was ist Protobuf?#

Protocol Buffers, oder kurz Protobuf, ist eine plattform- und sprachunabhängige Methode zur Serialisierung strukturierter Daten. Es wurde ebenfalls von Google entwickelt und dient als Grundlage für die Datenkommunikation in GRPC.

Also:

  • Protobuf = Datenformat
  • GRPC = Kommunikationsprotokoll

Beispiel#

Schauen wir uns ein einfaches Beispiel an. Lasst uns ein einfaches Protobuf-File erstellen, der die Kommunikation mit einem Backofen darstellt.

syntax = "proto3";

package smartoven;

// Dienst OvenControl zum Steuern des Backofens
service OvenControl {
  // Methode zum Backen eines Gegenstands
  rpc BakeItem (BakeRequest) returns (BakeResponse) {}
}

message BakeRequest {
  string item = 1;  // Was soll gebacken werden?
  int32 temperature = 2;  // Temperatur in Grad Celsius
  int32 duration = 3;  // Backdauer in Minuten
}

message BakeResponse {
  bool success = 1;  // War der Backvorgang erfolgreich?
  string message = 2;  // Zusätzliche Informationen oder Fehlermeldungen
}

Wir lesen das so: Wir haben einen Service OvenControl, der eine Methode BakeItem anbietet. Diese Methode erwartet ein BakeRequest-Objekt und gibt ein BakeResponse-Objekt zurück.

Die Objekte BakeRequest bestehen aus einem item (z.B. “Pizza”), einer temperature (z.B. 200) und einer duration (z.B. 20).

Das BakeResponse-Objekt besteht aus einem success-Flag und einer message.

Alle Datentypen sind in Protobuf statisch definiert und können auch nicht “falsch” übergeben werden. Das ist ein großer Vorteil gegenüber JSON oder XML. Auch gibt es weitere Datentypen, die hinzugefügt oder selbst definiert können, wie z.B. Timestamps, Enums oder Maps.

Zumdem beherrscht GRPC auch Streaming, also das Senden und Empfangen von mehreren Nachrichten. Das ist besonders nützlich, wenn wir z.B. eine Chat-Anwendung entwickeln. Auch bidirectional Streaming ist möglich, also das gleichzeitige Senden und Empfangen von Nachrichten.

Vorteile für Teams#

Stellen wir uns vor, dass dieses Projekt von mehreren Teams entwickelt wird. Jedes Team hat seine eigene Sprache und Technologie. Hier kommt mein Hautpargument für GRPC und Protobuf: Die Protobuf-Datei ist DIE Schnittstelle zwischen den Teams. Kein Rätselraten mehr, wie die Daten aussehen oder wie sie serialisiert werden. Die Datei stellt die “Wahrheit” und gleichzeitig Dokumentation für die Teams da.

Aber da hört es nicht auf: Wäre es nicht wundervoll, wenn jemand für uns den Server schreiben würde? Oder den Client? Oder beides? GRPC bietet uns die Möglichkeit, automatisch Clients und Server in verschiedenen Sprachen zu generieren. Das spart uns eine Menge Zeit und Fehler. Natürlich muss die Funktionalität noch implementiert werden, aber die Grundlagen sind schon mal gelegt - und das spart Zeit und Nerven.

Reflection#

Aber wäre es nicht toll, wenn wir - gerade für Tests, nun einfach solche Protobuf/GRPC Nachrichten einfach senden könnten? Oder Empfangen? Gar kein Problem! Wenn wir unseren Server mit Reflection starten (ist i.d.R. eine einfaches Flag), können wir mit GUI und cli clients einfach auf den Server zugreifen und Nachrichten senden. Ohne die Definition in die Hand nehmen zu müssen - die liefert der Server dem Client automatisch mit aus! Das ist ein mächtiges Werkzeug für die Entwicklung und das Testen.

Die Probleme#

Aber nun kommt der Pferdefuß: Dadurch, dass GRPC UDP nutzt, ist es nicht so einfach, GRPC im Browser zu nutzen. Hier gibt es aber auch wieder viele Lösungen:

  • REST Gateway: Ein Gateway, dass GRPC in REST umwandelt Viele GRPC Server bieten die Möglichkeit, automatisch ein REST Gateway zu starten. Hierbei wird der GRPC Server um einen REST Server erweitert, der die GRPC Anfragen in REST Anfragen umwandelt. Das ist eine einfache Möglichkeit, GRPC in Browsern zu nutzen. Und eine wundervolle Art auf GRPC zu migrieren, ohne alte Clients kaputt zu machen. Aber hier “verlieren” wir die Vorteile von GRPC - zumindest im Browser. Ach: Und Streaming geht auch nicht.
  • grpc-web: Eine Javascript Bibliothek, die es erlaubt mit GRPC zu kommunizieren - hier muss aber der Server auch entsprechend angepasst werden. Zudem gibt es nur Streaming von Server zu client. Schade.

Connect#

Meine Lieblingslösung für das Problem ist aber Connect. Connect ist eine GRPC kompatible Bibliothek, mit der ich meinen Server laufen lassen kann. Ich merke keinerlei Unterschied, da es ein vollwertiger GRPC Server ist.

Aber Connect hat eine Besonderheit: Connect auf dem Server ermöglicht es, dass sich Clients über Websockets verbinden können - von den Details bekomme ich aber wieder nichts mit - denn im Client verwende ich meine generierte connect Bibliothek, die sich um die Kommunikation kümmert. Und zwar MIT Streaming. Bidirektional. Wundervoll!

Kurzfassung Tools#

Wir machen also folgendes:

  1. Wir definieren unsere Schnittstelle in Protobuf
  2. Wir generieren uns unsere Server mit der connect Bibliothek
  3. Wir generieren uns unsere Webclients mit der conenct Bilbiothek
  4. Wir generieren unsere anderen Clients (z.B. andere Server) mit der GRPC Bibliothek oder auch connect.

Nun können wir zwischen Webclient und Server kommunizieren - und das ganze auch noch sicher, da Websockets verschlüsselt sind. Und vor allem: Wir haben die Typsicherheit von Protobuf und die Effizienz von GRPC. Wundervoll!

Fazit#

GRPC und Protobuf sind keine vorübergehenden Trends. Sie sind ausgereifte Technologien, die sich in der Praxis bewährt haben und kontinuierlich weiterentwickelt werden. Mit der Einführung von Connect wird die Verwendung von GRPC noch zugänglicher und vielseitiger.

Als Entwickler schätze ich die Zuverlässigkeit, Geschwindigkeit und Einfachheit, die GRPC bietet. Es ermöglicht mir, robuste und effiziente APIs zu erstellen, die sowohl für meine Teammitglieder als auch für die Endbenutzer einen Mehrwert bieten. Wenn Du noch nie mit GRPC gearbeitet haben, empfehle ich Ihnen, es in Ihrem nächsten Projekt auszuprobieren. Die klaren Schnittstellen, die Leistung und die Flexibilität sind es wert.