GraphQL als Alternative zu REST

Möchten verschiedene Software-Applikationen miteinander kommunizieren, so braucht es eine Programmierschnittstelle (API). Die API wird hierfür häufig mit REST gebaut, ohne sich über Alternativen zu erkundigen. GraphQL kann dir eine Alternative bieten und diese möchte ich folgend mit dir anschauen.

Was zeichnet GraphQL aus?

Im Gegensatz zu REST handelt es sich bei GraphQL um eine Abfragesprachenspezifikation mit Laufzeitumgebung, die Abfragen parsen und validieren kann. Für die Validierung der Abfragen kennt GraphQL deine Datenstruktur durch einen Entitätsgraph, den du definieren musst. GraphQL bietet das Tool GraphiQL, um während des Testings und der Entwicklung Programmierfehler zu entdecken.

Bei GraphQL gibt der Client genau an, welche Daten er bei einer Anfrage zurückerhalten möchte, und er weiss daher genau, was er erhalten wird. Aus diesem Grund können Daten, die der Client aus einer einzelnen Anfrage erhalten kann, aus verschiedenen Quellen stammen.

Möchtest du auf Daten zugreifen, die nicht bereits im Entitätsgraph enthalten sind, so muss der Entitätsgraph vorher angepasst werden mit der noch unbekannten Entität. Es können auch Felder und Entitäten im Entitätsgraph vorhanden sein, die von Queries nicht erfragt werden. Du kannst also weitere Entitäten in den Entitätsgraph aufnehmen, ohne bestehende Queries zu beeinflussen.

Um deine Datenstruktur mit Entitätsgraphen zu beschreiben, bietet dir GraphQL Konzepte wie Interfaces, Enumerationen, Listen etc. Um den Rahmen nicht zu sprengen, verweise ich auf die Erklärungen auf der GraphQL Webseite, sowie der Spezifikation selbst.

Die Rolle des Clients bei GraphQL

Durch die genaue Angabe in der Query, welche Daten der Client haben will, ist nun auch mehr Logik auf der Seite des Clients als bei REST vorhanden. Bei REST beginnt der Client mit einem Request auf eine URI und bekommt hierauf als Response eine Kopie einer Ressource, welche für deren Ressourcen wieder weitere URIs enthalten kann. Möchte nun der Client eine Ressource haben, für welche er deren Location durch die URI bekommen hat, so muss der Client einen weiteren Request auf diese URI machen. Dessen Response könnte wieder ein Request verlangen, und dessen Response könnte… Durch diese Mehrzahl an Anfragen addieren sich die Round-Trip-Zeiten, die das System bei REST träge machen können.

Der GraphQL Client muss selbst wissen, welche Daten er haben kann und muss in seiner Anfrage genau angeben, welche Daten er möchte. Dadurch hat der GraphQL-Client insofern mehr Verantwortung bekommen, die Datenstruktur kennen zu müssen, jedoch übernimmt der Server das Zusammentragen der Informationen. Hierdurch ist es bei GraphQL genau eine Round-Trip-Zeit, die für eine Abfrage beliebiger Tiefe benötigt wird.

Nehmen wir uns als Beispiel die Struktur des obigen Beispiels mit der Entität Person. Eine Person hat unter anderem ein Feld Freunde, welches eine Liste von Personen ist. Möchte man auf verschiedene Felder von einer Person mit der id = 2 und seiner beiden Freunde mit id = 23 und id = 32 zugreifen, so müssten nach REST drei Anfragen an den Server gesendet werden. Dementsprechend dauert es drei Round-Trip-Zeiten bis man zum gewünschten Ergebnis kommt. Bei GraphQL kann man hingegen in einer einzigen Anfrage alle benötigten Felder verlangen. Dies führt dazu, dass wir nach einer Round-Trip-Zeit bereits das Ergebnis haben.

Die GraphQL Anfrage bestehend aus einer HTTP-POST MethodeDie REST Anfrage bestehend aus drei HTTP-GET Methoden

Bei REST erhält der Client in der Response seine Möglichkeiten zur Manipulation von Daten vom Server in Form von Links. Bei GraphQL kann der Client statt einer Abfrage eine Mutation zur Manipulation von Daten abschicken. Wieder liegt es am Client und somit dessen Logik, zu wissen, ob und wie er die Daten manipulieren kann.

Fazit

Bei GraphQL gibt es die Hürde, ein Schema mit einem Entitätsgraph definieren zu müssen, was aber auch einige Vorteile mit sich bringt. Das Schema ermöglicht es dir, Tools wie GraphiQL zu verwenden, um Fehler in deinen Abfragen während der Entwicklung und des Testens zu finden. Es ist einfach, neue spezifizierte Abfragen zu erstellen, ohne Änderungen im Backend vornehmen zu müssen.

Dadurch dass bei GraphQL viel weniger Anfragen an den Server gehen müssen als bei REST, werden Paketumlaufzeiten (Round Trip Times, RTT) gespart. Ausserdem wird bei GraphQL die Bandbreite weniger belastet, weil nicht mehr Daten versendet werden, als angefragt wurden. Einzig bei den Abfragen werden durch den mitgesendeten Code wenige Kilobyte mehr gesendet. Insgesamt kann sich dies als erhebliche Performance-Verbesserung bei Anwendungen erweisen.

Mit GraphQL hast du eine Abfragesprachenspezifikation von Facebook, welche von verschiedenen Organisationen implementiert wird. Somit hast du die Wahl, welche Implementierung du nutzen möchtest.  Durch die wachsende Community verbessert sich GraphQL fortlaufend. Durch die ausschließliche Verwendung von POST-Methoden auf einem Endpunkt mit unterschiedlichen Anfragen ist beispielsweise das Caching in der Netzwerkschicht komplizierter als bei REST. Aufgrund der wachsenden Community gibt es dafür jedoch immer mehr Lösungen.