Читать книгу GraphQL - Dominik Kress - Страница 27

Für den Transport von Stub zu Server nutzt gRPC zwingend HTTP/2. Dadurch genießt das Framework die vollen Vorzüge des verbesserten Protokolls, wie die Möglichkeit, mehrere Requests gebündelt über nur eine TCP-Verbindung zu versenden. Die Vorteile von HTTP/2 lassen sich aber beispielsweise bei REST APIs und in anderen API-Spezifikationen und Technologien umsetzen. Es ist daher kein exklusiver Vorteil für gRPC. Der Zwang zu HTTP/2 führt jedoch zu einem strikteren Einsatz des Protokolls und damit zu einer Garantie der Vorteile.

Abseits von HTTP/2 bietet gRPC jedoch einen weiteren klaren Vorteil gegenüber REST APIs: Streaming. Wie im Proto-Buffer-Beispiel in Listing 1–8 zu sehen, ermöglicht gRPC durch die Verbindung zwischen Server und Stub bidirektionales Streaming von Datenpaketen.

Auch der Wechsel zwischen asynchronen und synchronen Verbindungen ist recht einfach umgesetzt. Hinzu kommen Features wie Deadlines und Timeouts oder auch die Möglichkeit, einen Call durch Metadaten zu erweitern. Trotz Streaming bietet gRPC jedoch noch keine Möglichkeit zum Broadcasting von Echtzeit-Kommunikation. Für eine Chat-Applikation ist das API-Framework also nicht geeignet.

Ein klarer Nachteil von gRPC ist zudem, dass es Browser nicht nativ unterstützen. Mit gRPC-Web gibt es zwar bereits einen Wrapper und einen Webclient, um das Framework auch für den Browser zu verwenden, doch der Fokus liegt ganz klar auf der optimalen Kommunikation zwischen Microservices.