GraphQL

Präzises Datenabrufen über einen einzigen typisierten Endpunkt

GraphQL ist eine offene Abfragesprache und Laufzeitumgebung für Programmierschnittstellen, mit der ein Client in einer einzigen Anfrage genau die Daten anfordert, die er braucht, beschrieben durch ein typisiertes Schema.

Eine klassische REST-Schnittstelle bietet viele feste Adressen, und jede liefert einen festen Ausschnitt. Wer Daten aus mehreren dieser Adressen zusammensetzen will, stellt mehrere Anfragen und bekommt dabei oft mehr Felder geliefert als gebraucht. GraphQL dreht dieses Verhältnis um: Es stellt einen einzigen Endpunkt bereit, und der Client beschreibt in seiner Anfrage die genaue Form der Antwort. Der Server liefert exakt diese Form zurück, nicht mehr und nicht weniger. Diese Seite beschreibt, was GraphQL ist, wofür es sich eignet und wo seine Grenzen liegen.

Eine Sprache, ein Schema, ein Endpunkt

GraphQL wurde ab 2012 intern bei Facebook entwickelt und 2015 als offene Spezifikation mit einer Referenzimplementierung veröffentlicht. Seit 2018 wird die Spezifikation nicht mehr von einem einzelnen Unternehmen, sondern von der GraphQL Foundation unter dem Dach der Linux Foundation gepflegt. Die Spezifikation selbst beschreibt GraphQL als Abfragesprache und Ausführungsmaschine für die Fähigkeiten und Anforderungen von Datenmodellen in Client-Server-Anwendungen. Wichtig ist die Abgrenzung: GraphQL ist keine Programmiersprache für beliebige Berechnungen und keine Datenbank, sondern eine Sprache, um Anwendungsserver abzufragen, unabhängig davon, welche Speicher dahinter liegen.

Im Zentrum steht das Schema. Der Anbieter eines GraphQL-Dienstes definiert Typen mit ihren Feldern und hinterlegt zu jedem Feld eine Auflösung, die den passenden Wert beschafft. Das Schema ist damit ein verbindlicher Vertrag zwischen Server und Client: Es legt fest, welche Daten abfragbar sind und welche Form sie haben. Aus diesem Vertrag ergeben sich die drei Operationsarten von GraphQL: Abfragen lesen Daten, Mutationen schreiben oder verändern sie, und Subscriptions liefern laufende Aktualisierungen. Diese strenge Typisierung rückt GraphQL nahe an den Gedanken einer API-First Entwicklung, bei der die Schnittstelle vor der Implementierung steht.

Was das Verfahren stark macht

Der spürbarste Gewinn ist das präzise Abrufen. Weil der Client die Form der Antwort vorgibt, entfällt das typische Zuviel oder Zuwenig an Daten: kein Feld zu viel, keine zweite Anfrage für ein fehlendes Feld. Mehrere zusammenhängende Ressourcen lassen sich in einer einzigen Anfrage holen, statt nacheinander mehrere Adressen aufzurufen.

Das typisierte Schema bringt einen zweiten Nutzen. Weil jede Anfrage gegen das Schema geprüft wird, fängt der Server unzulässige Anfragen ab, bevor er sie ausführt, und Werkzeuge können anhand des Schemas Autovervollständigung und Dokumentation anbieten. Hinzu kommt die Introspektion: Ein GraphQL-Dienst kann sein eigenes Schema beschreiben, sodass ein Client zur Laufzeit erfahren kann, welche Typen und Felder verfügbar sind. Genau diese Eigenschaft macht eine GraphQL-Schnittstelle zu einem Integrationspunkt: Sie eignet sich gut dafür, Daten aus einer Quelle gebündelt bereitzustellen und an eigene Oberflächen oder weiterverarbeitende Systeme anzubinden. Eine Wissensplattform wie Wiki.js etwa stellt ihre Inhalte über eine GraphQL-Schnittstelle bereit, was sie für eine Weiterverwendung in eigenen Anwendungen oder in einer Wissensabfrage zugänglich macht.

Die Gegenseite der Flexibilität

Dieselbe Flexibilität, die GraphQL stark macht, verschiebt einige Probleme vom Client auf den Server und schafft neue. Vier Punkte sind in der Praxis wiederkehrend.

• Zwischenspeicherung ist schwieriger als bei REST. Eine REST-Adresse ist ein global eindeutiger Bezeichner, an dem die üblichen HTTP-Mechanismen zur Zwischenspeicherung ansetzen. GraphQL kennt keinen solchen adressbasierten Schlüssel, weil alle Anfragen über denselben Endpunkt laufen. Als Gegenmassnahme empfiehlt es sich, jedem Objekt ein global eindeutiges Feld als Schlüssel mitzugeben, an dem clientseitige Speicher ansetzen können.
• Das N-plus-1-Problem auf dem Server. Eine naiv geschriebene Auflösung kann pro Element einer Liste eine eigene Datenbankabfrage auslösen: eine Anfrage für die Liste, dann eine weitere für jedes Element. Aus einer Anfrage werden so viele. Die übliche Gegenmassnahme ist das Bündeln solcher Abfragen über kurze Zeitfenster mit einem Werkzeug wie DataLoader.
• Kosten und Komplexität einer Anfrage. Weil der Client die Form der Anfrage frei wählt, kann eine einzelne, tief verschachtelte Anfrage den Server stark belasten. Der Server kann nicht immer im Voraus wissen, wie teuer eine Anfrage wird. Übliche Schutzmassnahmen sind eine Begrenzung der Verschachtelungstiefe, eine Kostenabschätzung über Gewichte je Feld sowie eine Begrenzung der Anfragerate.
• Eine Lernkurve. Schema-Entwurf, Auflösungen, Bündelung und Kostenkontrolle sind eigene Themen. Ein Team, das von REST kommt, muss diese Konzepte erst aufbauen, bevor der Gewinn an Präzision die anfängliche Mehrarbeit aufwiegt.

Diese Punkte sind keine Ausschlussgründe, sondern der Preis für die Flexibilität. Bemerkenswert ist, dass die Spezifikation bei mehreren dieser operativen Fragen, etwa der Zwischenspeicherung und der Kostenkontrolle, bewusst schweigt und sie den Implementierungen überlässt.

Einordnung

GraphQL ist eine Art, eine Schnittstelle zu bauen, nicht die einzige. Es konkurriert nicht mit der Datenbank dahinter, sondern liegt davor und bündelt deren Daten zu einem Graphen, den der Client befragt. Wo eine REST-Schnittstelle viele feste Ausschnitte über viele Adressen anbietet, bietet GraphQL eine flexible Sicht über einen Endpunkt. Beide Ansätze lösen die Frage, wie Systeme Daten austauschen, und stehen damit neben anderen Integrationsmustern wie dem Model Context Protocol, das KI-Modelle zur Laufzeit mit Datenquellen verbindet. GraphQL beantwortet die Frage, wie ein Client genau die Daten erhält, die er anfordert.

Referenzen

• GraphQL Foundation GraphQL Specification. Die Sprachspezifikation; aktuelle stabile Ausgabe vom Oktober 2021, beschreibt Typsystem, Abfragesprache, Validierung, Ausführung und Introspektion. (Oktober 2021). spec.graphql.org/October2021/
• GraphQL Foundation Best Practices und Performance. Offizielle Leitlinien zu Zwischenspeicherung, dem N-plus-1-Problem und dem Bündeln von Abfragen mit DataLoader. (2026). graphql.org/learn/performance/
• GraphQL Foundation Security. Schutz vor teuren Operationen durch Begrenzung von Tiefe, Komplexität und Anfragerate. (2026). graphql.org/learn/security/
• Wikipedia GraphQL. Überblick zu Entstehung bei Facebook ab 2012, Veröffentlichung 2015 und Übergang an die GraphQL Foundation 2018. (2026). en.wikipedia.org/wiki/GraphQL

---

Verwandte Themen

• API-First, der Entwurfsansatz, der die Schnittstelle und ihren Vertrag vor die Implementierung stellt.
• Wiki.js, eine Wissensplattform, die ihre Inhalte über eine GraphQL-Schnittstelle bereitstellt.
• MCP (Model Context Protocol), ein anderes Integrationsmuster, das KI-Modelle zur Laufzeit an Datenquellen anbindet.