GraphQL vs. REST: Vor- und Nachteile im Vergleich

REST ist der De-facto-Standard für APIs, doch ist dieser Ansatz immer die beste Lösung?

Schnelle Antwortzeiten sind in modernen Benutzeroberflächen das A und O, denn die Geduld und Akzeptanz für langsame Oberflächen wird immer geringer. Klassische REST-APIs bieten jedoch nicht immer die passenden Daten für eine Ansicht, sodass mehrere Requests abgesetzt werden müssen, was den Aufbau verlangsamt. Ein Workaround besteht darin, möglichst alle Daten in einem Request zu senden, wobei aber nicht an allen Stellen all diese Informationen benötigt werden, wodurch die Antwortgröße unnötig in die Höhe getrieben wird.

Hier kommt GraphQL ins Spiel, das sich inzwischen als flexible und effiziente Alternative zu herkömmlichen REST-APIs etabliert hat. Diese Technologie bietet eine präzise und leistungsfähige Abfragesprache, die es Entwicklern ermöglicht, exakt die benötigten Daten anzufordern und zu erhalten. Doch was sind weitere Eigenheiten, die GraphQL zu einer idealen Lösung für moderne Web- und Mobilanwendungen macht?

GraphQL und dessen Vor- und Nachteile

GraphQL hat sich als flexible und leistungsfähige Alternative zu traditionellen REST-APIs etabliert, bietet aber auch spezifische Herausforderungen. Im Folgenden will ich die wichtigsten Vor- und Nachteile von GraphQL im Vergleich zu REST erläutert, um Ihnen zu helfen, die beste Entscheidung für Ihre spezifischen Anforderungen zu treffen.

Vorteile von GraphQL

Flexibilität, Reduzierung von Over- und Underfetching: GraphQL bietet eine hohe Flexibilität, indem es Clients ermöglicht, nur die Daten abzurufen, die sie benötigen, und dies in einer einzigen Anfrage. Anstatt mehrere Endpunkte zu durchlaufen, um verschiedene Daten zu erhalten, können alle benötigten Informationen in einer einzigen, strukturierten Abfrage angefordert werden. Dies reduziert die Anzahl der Netzwerkaufrufe und erhöht die Effizienz der Datenübertragung. Beispielsweise könnte eine mobile Anwendung, die Benutzer- und Adress-Daten benötigt, diese in einer einzigen Abfrage anfordern, anstatt separate Anfragen für Benutzer- und Adress-Endpunkte zu stellen.
Overfetching tritt auf, wenn mehr Daten als nötig abgerufen werden, was die Bandbreite belastet und die Leistung beeinträchtigt. Underfetching passiert, wenn nicht genügend Daten bereitgestellt werden und zusätzliche Anfragen erforderlich sind. GraphQL löst diese Probleme, indem es Clients erlaubt, genau die benötigten Daten zu spezifizieren. Dies bedeutet, dass nur relevante Daten übertragen werden, was die Leistung verbessert und die Netzwerkbelastung verringert. Ein Beispiel hierfür wäre, dass von den Benutzer-Daten nur der volle Name und die ID benötigt werden, nicht aber z.B. das Geburtsdatum. GraphQL erlaubt bei jeder Anfrage die gezielte Auswahl der Felder.

Versionskontrolle: In traditionellen REST-APIs kann die Einführung neuer Versionen komplex und disruptiv sein, da Änderungen an den Endpunkten bestehende Integrationen brechen können. GraphQL umgeht dieses Problem, indem es eine einheitliche Schnittstelle bietet, über die alle Daten abgefragt werden können. Änderungen am Schema, wie das Hinzufügen neuer Felder oder Typen, beeinflussen bestehende Abfragen nicht, solange die bestehenden Felder und Typen unverändert bleiben. Dies macht das API-Management flexibler und reduziert die Notwendigkeit, verschiedene API-Versionen zu pflegen.

Schema-Introspektion: GraphQL bietet ein eingebautes Introspektionssystem, das es Clients ermöglicht, das Schema und die verfügbaren Datenstrukturen dynamisch abzufragen. Entwickler können so die API erkunden und herausfinden, welche Abfragen und Mutationen möglich sind, ohne auf externe Dokumentation angewiesen zu sein. Tools wie GraphiQL und GraphQL Playground nutzen diese Introspektion, um interaktive Schnittstellen bereitzustellen, in denen Entwickler Abfragen testen und die API-Dokumentation automatisch generieren können. Dies kann die Entwicklung und Wartung von Anwendungen erheblich erleichtern.

Nachteile von GraphQL

Lernkurve und Zielgruppe: Der Einstieg in GraphQL kann komplexer sein als bei REST, insbesondere für Entwickler, die mit der GraphQL-Abfragesprache und den damit verbundenen Konzepten nicht vertraut sind. REST baut auf HTTP-Methoden (GET, POST, PUT, DELETE) auf, die vielen Entwicklern bekannt sind. GraphQL hingegen erfordert ein Verständnis der Abfragesprache, der Typensysteme und der Resolver-Logik, die erforderlich ist, um Anfragen auf dem Server zu verarbeiten. Dies kann die Lernkurve erhöhen und zusätzliche Schulung erfordern. Es ist wichtig sicherzustellen, dass die Zielgruppe der API in der Lage und bereit ist, GraphQL zu nutzen. Eine erfolgreiche Implementierung auf der Serverseite bringt nichts, wenn die Clients die API nicht verwenden können oder wollen.

Caching: Caching-Mechanismen sind bei GraphQL schwieriger zu implementieren als bei REST. REST-APIs können HTTP-Caching-Methoden wie ETag, Last-Modified und Cache-Control effektiv nutzen, um Daten im Browser oder bei Proxy-Servern zu cachen. GraphQL hingegen führt häufig zu komplexeren Anfragen, die nicht so leicht von standardmäßigen HTTP-Caching-Mechanismen profitieren können. Um Caching in GraphQL zu implementieren, sind oft spezifische Strategien und zusätzliche Bibliotheken erforderlich, wie z.B. Apollo Client's Cache.

Overhead: Obwohl GraphQL-Anfragen flexibel sind, können sie aufgrund der granularen Datenanforderungen auch einen höheren Server-Overhead verursachen. Bei sehr komplexen Abfragen oder tief verschachtelten Datenstrukturen kann die Verarbeitung auf dem Server ressourcenintensiver sein. Dies kann die Serverleistung beeinträchtigen und erfordert möglicherweise zusätzliche Optimierungen, um effizient zu arbeiten. Besonders bei großen Systemen mit vielen verschachtelten Abfragen kann dies zu einer signifikanten Belastung führen.

Sicherheit: GraphQL bietet flexible Abfragemöglichkeiten, was jedoch auch Sicherheitsrisiken mit sich bringen kann. Da es Clients standardmäßig erlaubt ist komplexe und verschachtelte Abfragen zu erstellen, besteht die Gefahr von Denial-of-Service (DoS)-Angriffen durch sehr tief verschachtelte oder ressourcenintensive Abfragen. Zudem können fehlende Zugriffskontrollen dazu führen, dass sensible Daten unabsichtlich offengelegt werden. Es ist wichtig, Sicherheitsmaßnahmen wie Abfragekomplexitätsanalyse, Tiefenbegrenzungen, Rate-Limiting und robuste Authentifizierungs- und Autorisierungsmechanismen zu implementieren, um diese Risiken zu mindern. Das soll nicht bedeuten, dass GraphQL inherent unsicher ist, aber bei der Implementierung müssen die spezifischen Sicherheitsrisiken den Entwicklern bekannt sein, um diese zu minimieren.

Letztendlich hängt die Wahl zwischen GraphQL und REST von den Anforderungen des Projekts, den Kenntnissen des Entwicklungsteams und Faktoren von Dritten, die die Schnittstelle benutzen sollen, ab.

Ein kurzes Beispiel

In diesem Beispiel möchte ich kurz die Schema-Introspektion und Abfrage an Hand einer Countries GraphQL API demonstrieren. Dabei handelt es sich um eine öffentliche GraphQL API für Informationen über Länder, Kontinente und Sprachen.

Eine GraphiQL-Playground zum selbst ausprobieren ist hier erreichbar: https://countries.trevorblades.com/

Dank der Schema-Introspektion können alle Anfrage-Typen abgerufen werden, ohne sich auf eine potenziell veraltete Dokumentation verlassen zu müssen. Auf die gleiche Weise können die über die Schnittstelle bereitgestellten Typen abgefragt werden. Wie zu erwarten, stellt diese unter anderem Kontinente, Länder und Sprachen bereit, und auch deren Felder und Typen sind explorierbar. Dank GraphiQL werden diese Werte automatisch ermittelt und für eine rudimentäre Dokumentation sowie Autovervollständigung im Query-Browser verwendet.

Aber wie sieht nun eine echte Anfrage gegen die GraphQL API aus? Angenommen, wir wollen eine Liste aller Kontinente samt deren Länder in einem Übersichtsfenster in unserer fiktiven Test-App darstellen. Dafür benötigen wir die Namen der Kontinente sowie eine Liste ihrer Länder samt Namen und, zur schönen Darstellung, noch das Flaggen-Emoji. Bei einer klassischen REST-Schnittstelle wären das vermutlich zwei Anfragen gegen die Länder- und Kontinent-Endpunkte, und in der Antwort erhalten wir alle verfügbaren Attribute, statt nur der Handvoll, die wir für den aktuellen Bildschirm wirklich nutzen wollen. In GraphQL könnte die Anfrage so aussehen:

Bei einem direkten Vergleich in Postman ist die GraphQL-Abfrage, die nur die gewünschten Attribute zurückgibt, je nach Umfang um den Faktor 6 bis 10 kleiner als eine Anfrage mit allen möglichen Attributen (11KB vs 65/116KB). Der Unterschied im Umfang hängt davon ab, ob bei den Ländern auch deren Unterteilungen (Subdivisions) zurückgegeben werden oder nicht.

Dies ist nur ein grober Einstieg in die technischen Möglichkeiten von GraphQL. Natürlich sind auch ändernde Anfragen, in GraphQL Mutationen genannt, sowie Pagination und Subscriptions verfügbar. Letztere ermöglichen es Clients, Echtzeit-Updates von einem Server zu erhalten, indem sie sich für bestimmte Ereignisse oder Datenänderungen anmelden. Aber das schauen wir uns potentiell in einem zukünftigen Beitrag genauer an.

Ist GraphQL damit die Lösung aller Probleme?

Nein, wie immer kommt es auf den Anwendungsfall an.

Ein Nachteil ist die Verbreitung und Entwicklererfahrung, da besonders bei offenen APIs, bei denen man keine Kontrolle über die Konsumenten hat, Nutzer möglicherweise eine REST-basierte Lösung bevorzugen, weil sie damit mehr Erfahrung haben. Zudem ist GraphQL nicht per se unsicherer als Alternativen, bietet jedoch neue Angriffsvektoren, mit denen Entwickler sich erst vertraut machen müssen.

GraphQL lohnt sich besonders in Anwendungsfällen, bei denen die angefragten Daten clientseitig stark variieren. Der Ansatz zeigt seine Stärken vor allem dann, wenn die Client-Landschaft divers ist und unterschiedliche Anforderungen an die Datenabfragen stellt. Wenn das Client- und Backend-Team gut zusammenarbeitet, kann die Nutzung von GraphQL im richtigen Umfeld die Komplexität reduzieren, den Wartungsaufwand verringern und die Traffic-Last senken. Auch aus der Perspektive der Green IT bietet GraphQL Vorteile: Eine möglichst kleine Response verbraucht weniger Bandbreite und schont damit nicht nur die Umwelt, sondern auch die Batterien mobiler Endgeräte, was sowohl der Umwelt als auch den Anwendern zugutekommt.

Die Entscheidung zwischen GraphQL und REST muss jedoch kein Entweder-oder sein. Je nach Anforderungen können beide Technologien auch nebeneinander existieren, wie es beispielsweise bei den Shopify Admin APIs der Fall ist. Hier können Kunden selbst entscheiden, welche der beiden APIs für ihren Anwendungsfall die geeignete ist.

Wenn Sie eine maßgeschneiderte Lösung benötigen, unterstützen wir von exensio Sie gerne. Kontaktieren Sie uns, um die besten Technologien für Ihre Anforderungen zu finden und zu implementieren.