dafür, dass der Funktionsaufruf an den Server weitergegeben, verarbeitet und beantwortet wird.
Abb. 1–3 Das gRPC-Konzept nach Googles gRPC-Guide [23]
Vor- und Nachteile von gRPC
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.
1.4.5GraphQL
GraphQL wurde 2015 von Facebook für seine eigene Facebook-API veröffentlicht und ist die Spezifikation einer plattformunabhängigen Query-Sprache für APIs [19]. GraphQL dient als eine Art Übersetzer der Kommunikation zwischen Server und Client. Diese erfolgt wie bei REST über HTTP in einem Request-Response-Schema. Jedoch stellt das API nicht für jedes Objekt einen eigenen Endpunkt, den der Client für die entsprechende Ressource ansprechen kann. Vielmehr stellt ein GraphQL-API nur noch einen Endpunkt, über den der Client mit einem Request lesende Operationen über sogenannte Querys oder schreibende Operationen über Mutationen durchführen kann.
Das Graphenschema
Serverseitig muss hierfür ein graphenbasiertes Schema der Daten genutzt werden. Das kann wie folgt aussehen:
type Query {
hero: Character
}
type Character {
name: String
friends: [Character]
homeworld: Planet
species: Species
}
type Planet {
name: String
position: String
}
type Species {
name: String
lifespan: Int
origin: Planet
}
Listing 1–9 Graphenschema
Wie man an diesem Beispiel erkennen kann, verweist ein GraphQL-Schema von einem Objekttyp – also einer im Schema definierten Art eines Objekts – auf einen anderen Objekttyp, wenn es eine Beziehung der beiden zueinander gibt. Dieses Graphenschema ist sozusagen eine Sammlung aller Fragen, die ein Entwickler stellen könnte.
Die GraphQL-Querys
Requests für lesenden Zugriff stellt der Client über einen Query. Dieser kann wie folgt aussehen:
{
hero (name="Luke Skywalker"){
name
homeworld {
name
position
}
species {
name
origin {
name
}}}}
Listing 1–10 GraphQL Request Query
In diesem Fall wäre die Response vonseiten des Servers folgende:
{
"hero": {
"name": "Luke Skywalker",
"homeworld": {
"name": "Tatooine",
"position"; "R-16"
},
"species": {
"name": "human",
"origin": {
"name": "undefined"
}}}}
Listing 1–11 GraphQL Response
Ein Query ist eine klare Anfrage, welche spezifischen Informationen der Entwickler vom Server benötigt. Die Rückgabe enthält dabei bereits alle Informationen, auch wenn eine Anfrage Felder von mehreren Objekten benötigt. Anders als bei den einzelnen Ressourcen-Endpunkten von REST, können über einen einzigen Endpunkt alle relevanten Informationen abgerufen und modifiziert werden.
Die Querys für die lesenden Zugriffe können unter anderem, wie im oberen Beispiel mit dem Heldenname, (auch mehrfache) Parameter enthalten. Sie bieten Aliases, um mehrfach benötigte Teile der Daten unterschiedlich zu benennen, Fragmente, um Teile von sehr großen Querys in mehrmals aufrufbare Subquerys zu extrahieren, Variablen und auch Direktiven.
Mittlerweile gibt es viele Frameworks, die aus den definierten GraphQL-Schemas sowohl Client- als auch Servercode ableiten und automatisch generieren. Das erleichtert die Arbeit signifikant und unterstützt mit den definierten Schemas als API Contract den Contract-First-Ansatz.
1.4.6Die Technologien im Vergleich
REST APIs sind und bleiben wohl auch noch für eine Weile der Standard im Web. Es ist ein einfaches, universelles und trotzdem sehr mächtiges Konzept. Doch in seiner einfachen Form ist es letztendlich auch etwas eingeschränkt.
Die JSON:API-Spezifikation geht einen Schritt weiter. Obwohl sie auch durch ihre Einfachheit besticht, legt sie eine ordentliche Portion Effizienz und Kommunikationsoptimierung oben drauf. Sie bleibt dabei jedoch – auch vom Umfang der Möglichkeiten – leichtgewichtiger als GraphQL mit seinen dedizierten Schemas.
GraphQL und gRPC bieten nahezu den vollen Umfang an möglicher Funktionalität in Sachen Kommunikation. GraphQL ist dabei eher Daten-, gRPC eher funktionsorientiert. Die Abbildung nahezu jeglicher Komplexität zieht jedoch einen Overhead nach sich: Ob nun die klare Schemadefinition in GraphQL oder die Proto-Buffer-Definitionen, beide Ansätze benötigen zusätzlichen Aufwand beim Erstellen