Leitfäden

GraphQL ist eine Abfragesprache für APIs und zugleich eine Laufzeitumgebung, die diese Abfragen mit Ihren Daten beantwortet. 2012 bei Facebook entwickelt und 2015 als Open Source veröffentlicht, gibt es dem Client — einem Web-Frontend, einer mobilen App oder einem anderen Dienst — eine einzige, präzise Möglichkeit, von einem Server genau die Daten anzufordern, die er braucht, nicht mehr und nicht weniger. Statt dass der Server die Form jeder Antwort bestimmt, beschreibt der Client, was er möchte, und der Server liefert die passenden Daten in genau dieser Form.

Diese eine Idee unterscheidet GraphQL vom REST-Stil, der ihm vorausging. Bei REST rufen Sie typischerweise mehrere Endpunkte auf, von denen jeder eine feste, vom Server im Voraus definierte Struktur zurückgibt. Bei GraphQL senden Sie eine einzige Anfrage an einen einzigen Endpunkt und geben die gewünschten Felder an; die Antwort spiegelt Ihre Anfrage wider. Das Ziel ist nicht, REST überflüssig zu machen, sondern konkrete Probleme zu lösen, die feste Endpunkte verursachen, wenn eine Anwendung und ihre Daten wachsen.

Wie GraphQL funktioniert: das Schema

Im Zentrum von GraphQL steht das Schema, ein stark typisierter Vertrag, der jeden verfügbaren Datentyp und die Beziehungen zwischen diesen Typen beschreibt. Weil das Schema explizit und typisiert ist, wissen beide Seiten im Voraus, was möglich ist: Werkzeuge können eine Abfrage validieren, bevor sie überhaupt ausgeführt wird, Editoren können Felder automatisch vervollständigen, und Dokumentation lässt sich automatisch aus dem Schema selbst erzeugen. Diese selbstbeschreibende Natur ist einer der praktischsten Vorteile von GraphQL.

Eine GraphQL-Abfrage liest sich fast wie das JSON, das sie zurückgibt. Sie benennen die gewünschten Felder, verschachteln verwandte Felder darin, und der Server durchläuft das Schema, um jedes einzelne aufzulösen. Derselbe Endpunkt akzeptiert auch Mutationen, die Daten verändern, und Subscriptions, mit denen der Server über eine dauerhafte Verbindung Aktualisierungen an den Client sendet. Abfragen, Mutationen und Subscriptions sind die drei Operationstypen, die die Spezifikation definiert.

Over-Fetching und Under-Fetching

Zwei Probleme fester REST-Endpunkte erklären einen Großteil der Anziehungskraft von GraphQL: Over-Fetching und Under-Fetching. Over-Fetching bedeutet, dass ein Endpunkt weit mehr Daten zurückgibt, als ein Bildschirm benötigt, und so Bandbreite verschwendet. Under-Fetching ist das Gegenteil — ein einzelner Endpunkt liefert nicht genug, sodass der Client mehrere Roundtrips machen muss, um eine einzige Ansicht zusammenzusetzen. Da ein GraphQL-Client genau die benötigten Felder in einer Anfrage abfragt, umgeht er beides auf einmal.

• Abfragesprache für APIs: der Client fragt genau die benötigten Felder ab
• Stark typisiertes Schema = selbstdokumentierend, validiert, autovervollständigbar
• Drei Operationen: Abfragen (lesen), Mutationen (schreiben), Subscriptions (push)
• Löst Over- und Under-Fetching von REST in einer einzigen Anfrage
• Kompromisse: schwierigeres HTTP-Caching, Kosten-Schutzmaßnahmen; REST einfacher für kleine APIs

GraphQL und Front-end-Frameworks

Diese Präzision ist besonders wertvoll für Frontend-Frameworks wie React, Vue, Svelte und Angular, bei denen eine Komponente oft einen bestimmten Ausschnitt der Daten braucht. Eine Komponente kann genau die Felder anfordern, die sie rendert, und während sich die Oberfläche weiterentwickelt, entwickelt sich die Abfrage mit, ohne darauf zu warten, dass ein Backend-Team einen neuen Endpunkt baut. Ausgereifte Client-Bibliotheken ergänzen darüber hinaus Caching, das Bündeln von Anfragen und State-Management, weshalb GraphQL in komponentenbasierten Frontends populär wurde.

Die ehrlichen Kompromisse

GraphQL ist nicht automatisch die richtige Wahl, und ehrlich über seine Kompromisse zu sein, ist wichtig. Sein einzelner dynamischer Endpunkt erschwert das einfache HTTP-Caching, das REST genießt, sodass das Caching meist in den Client oder eine spezialisierte Schicht wandert. Nachlässig geschriebene Abfragen können tief verschachtelte Daten anfordern und den Server belasten, weshalb produktive APIs Tiefenbegrenzungen, Kostenanalysen und weitere Schutzmaßnahmen hinzufügen. Für eine kleine API mit stabilen, vorhersehbaren Anforderungen ist REST oft einfacher und vollkommen ausreichend.

Was GraphQL nicht ist

Es lohnt sich auch klarzustellen, was GraphQL nicht ist. Es ist weder eine Datenbank noch eine Speicher-Engine — es sitzt vor Ihren bestehenden Datenquellen, seien es Datenbanken, REST-APIs oder andere Dienste, und Resolver holen die Daten von dort. Es ist auch nicht an eine einzige Sprache oder ein Framework gebunden; Server und Clients gibt es im gesamten Ökosystem, und die Spezifikation wird von der herstellerneutralen GraphQL Foundation gepflegt, nicht von einem einzelnen Unternehmen.

GraphQL vs REST: wie man wählt

Die Wahl zwischen GraphQL und REST hängt von der Form Ihrer Anwendung ab, nicht von der Mode. GraphQL glänzt, wenn viele verschiedene Clients unterschiedliche Ausschnitte eines komplexen, vernetzten Datengraphen benötigen, wenn Frontend- und Backend-Teams unabhängig voneinander arbeiten wollen, oder wenn das Reduzieren von Roundtrips auf langsamen Verbindungen Priorität hat. REST bleibt eine ausgezeichnete Standardwahl für einfachere Dienste, öffentliche APIs, die von HTTP-Caching profitieren, und Teams, die seine Allgegenwart und Einfachheit schätzen.

Schlicht verstanden, ist GraphQL eine Möglichkeit, den Client genau die Daten anfordern zu lassen, die er möchte, beschrieben durch ein typisiertes Schema, ausgeliefert über einen einzigen Endpunkt. Es ersetzt weder Datenbanken noch REST noch Ihre bestehenden Dienste; es organisiert, wie Clients mit ihnen sprechen. Zu wissen, welche Probleme es löst — und welche Caching- und Komplexitätskosten es einführt — erlaubt es Ihnen, danach zu greifen, wenn es wirklich passt, und es liegen zu lassen, wenn REST das bessere Werkzeug ist.