GraphQL als Alternative zu REST

Wie implementiere ich einen GraphQL-Server?

Eine GraphQL-Schnittstelle serverseitig zur Verfügung zu stellen, ist ähnlich einfach und intuitiv wie das Erstellen von Abfragen. Im Wesentlichen müssen Schema und Resolve-Funktionen definiert werden. Das Schema definiert die Knoten und die Relationen des Graphen, der die eigentlichen Daten darstellt.

Bezogen auf das vorherige Beispiel mit dem Benutzer würde der Graph mit zugehörigen Typ-Definitionen wie folgt aussehen:

Der Query-Datentyp bildet den Einstieg des Schemas und ist somit der Startknoten im Graphen. Das bedeutet, dass jede Abfrage des Clients mit einem der Felder des Query-Datentyps beginnen muss, da die Felder die Kanten im Graphen darstellen. Vom Startknoten ausgehend können alle anderen Knoten des Graphen erreicht werden.

Während innerhalb des Schemas die Datentypen und die Relationen zueinander definiert werden, beschreiben die Resolve-Funktionen, wie beziehungsweise woher die eigentlichen Daten geladen werden. Sie legen fest, wie die Felder oder Typen des Schemas mit einem oder mehreren Backends verbunden sind. Woher genau die Daten kommen, ist nicht festgelegt. So ist es möglich, in einer Resolve-Funktion beispielsweise eine REST-Schnittstelle aufzurufen oder direkt eine Datenbank anzufragen.

Nachdem Schema und Resolver implementiert worden sind, kann die Abfrage des Clients ausgewertet werden. Dies erfolgt in drei Schritten:

• 1. Parsen: Hier findet eine rein syntaktische Prüfung der Abfrage statt.

• 2. Validieren: Hier wird die Abfrage mithilfe des Schemas validiert. Es wird geprüft, ob die Felder der Abfrage mit denen des Schemas übereinstimmen.

• 3. Ausführen: Ausgehend vom Startknoten (Query-Datentyp) werden die Resolve-Funktionen der Felder ausgeführt, um das in der Abfrage angeforderte Datenobjekt nacheinander zusammen zu bauen.

Vor- und Nachteile von GraphQL

GraphQL löst unter anderem das Problem mit Over- und Under-Fetching in einer intuitiven und einfachen Art und Weise. Anders als in REST-basierten APIs muss der Entwickler keine eigene Abfragesprache entwickeln, um die API beziehungsweise Schnittstellen flexibler zu machen, sondern kann dafür auf GraphQL als Standard mit entsprechenden Referenzimplementierungen zurückgreifen.

Darüber hinaus wird gegenüber REST-basierter APIs die Kopplung zwischen Client und Server verringert, da der Client nicht mehr auf vorgefertigte und spezialisierte Schnittstellen angewiesen ist. Stattdessen können die im Kontext des Clients benötigten Daten individuell angefragt beziehungsweise manipuliert werden.

Der Client wird vom reinen Konsumenten zum Ersteller seiner eigenen Schnittstellen. Dies ist unter anderem dann hilfreich, wenn dieselbe API für unterschiedliche Plattformen – wie iOS, Android oder Web – verwendet werden soll.

Alle diese Vorteile kommen auch mit einer Reihe von Nachteilen. Themen wie beispielweise Fehlerbehandlung, Caching oder Autorisation sind in GraphQL teilweise schwieriger umzusetzen, als in REST. Außerdem werden einige Themen in der Spezifikation nicht erwähnt, wie beispielsweise das Hochladen von Dateien. An diesen Stellen kann jedoch meistens auf Best Practices zurückgegriffen werden.

Insgesamt kann GraphQL je nach Anwendungsfall eine gute Alternative zu REST-basierten APIs sein. Besonders wenn die Schnittstellen sehr flexibel sein müssen, kann GraphQL den Aufwand der Implementierung reduzieren. In jedem Fall ist es nötig, REST und GraphQL zunächst nach Anwendungsfall beziehungsweise Anforderungen gegeneinander abzuwägen und erst dann eine Entscheidung zu treffen.

* David Klassen hat Informatik an der TU Dortmund studiert und ist aktuell Software Engineer bei der adesso AG. Dort beschäftigt er sich neben Kundenprojekten mit der Nutzung und Weiterentwicklung von Open-Source-Software. In diesem Zusammenhang hat er bereits erfolgreich selber an einigen Open-Source-Projekten mitgewirkt.

(ID:45487638)