Was ist GraphQL?

GraphQL ist eine Abfragesprache für Programmierschnittstellen (APIs), mit der ein Programm genau die Daten anfordert, die es braucht – nicht mehr und nicht weniger. Statt vieler fester Adressen gibt es einen einzigen Zugangspunkt, an den der Client eine strukturierte Anfrage schickt und passgenau die gewünschten Felder zurückbekommt.

Entwickelt wurde GraphQL ab 2012 bei Facebook für die mobile App, 2015 wurde es als offene Spezifikation veröffentlicht. Heute pflegt es die GraphQL Foundation unter dem Dach der Linux Foundation. Viele Shopsysteme, Headless-CMS und SaaS-Dienste bieten inzwischen neben REST auch eine GraphQL-Schnittstelle an.

Was GraphQL ist

Im Kern besteht GraphQL aus zwei Teilen:

• Schema: Der Server beschreibt verbindlich, welche Datentypen es gibt und wie sie zusammenhängen – etwa „Kunde hat Bestellungen, Bestellung hat Positionen, Position hat Artikel“. Dieses Schema ist gleichzeitig die Dokumentation.
• Abfragen: Der Client formuliert seine Anfrage in genau dieser Struktur. Lesende Anfragen heißen Queries, ändernde Mutations, und für Benachrichtigungen in Echtzeit gibt es Subscriptions.

Weil das Schema streng typisiert ist, weiß jede Seite vorher, welche Felder es gibt und welchen Datentyp sie haben. Entwicklungswerkzeuge können daraus automatisch Vorschläge und Prüfungen ableiten, und Änderungen am Schema fallen früh auf, statt erst im laufenden Betrieb.

Das „Graph“ im Namen meint die Verknüpfung der Daten, keine Grafik. Mit einer Datenbanksprache wie SQL hat GraphQL trotz des „QL“ wenig zu tun: Es legt nicht fest, wie die Daten gespeichert werden, sondern nur, wie man sie über die Schnittstelle abfragt.

So funktioniert eine GraphQL-Abfrage

Angenommen, ein Außendienst-Tablet soll zu einem Kunden nur Name, Ort und die letzten drei Bestellungen mit Betrag anzeigen. Die Anfrage sieht vereinfacht so aus:

{
  kunde(nummer: "10452") {
    name
    ort
    bestellungen(letzte: 3) { datum betrag }
  }
}

Der Server antwortet in derselben Form, üblicherweise als JSON. Hinter den Kulissen ruft er für jedes Feld eine kleine Funktion auf, einen sogenannten Resolver, der die Daten aus Datenbank, ERP oder einem anderen Dienst holt. Für den Client spielt es keine Rolle, woher die Felder stammen.

GraphQL oder REST?

Die bekannteste Alternative ist die REST-API, bei der jede Ressource eine eigene Adresse hat. Beide Ansätze haben ihren Platz:

Merkmal	REST	GraphQL
Zugangspunkte	Viele Adressen, eine je Ressource	Ein Zugangspunkt für alles
Datenumfang	Server legt fest, was zurückkommt	Client wählt die Felder
Verknüpfte Daten	Oft mehrere Aufrufe nacheinander	Eine Anfrage über mehrere Ebenen
Caching	Einfach über HTTP	Aufwendiger, meist im Client
Einstieg	Sehr verbreitet, leicht zu testen	Mehr Konzeptarbeit am Schema

Faustregel: GraphQL spielt seine Stärke aus, wenn viele unterschiedliche Oberflächen – Web, App, Kundenportal – auf dieselben verknüpften Daten zugreifen. Für eine einfache Maschine-zu-Maschine-Verbindung zwischen zwei Systemen ist REST oft die schlichtere Wahl.

Wo GraphQL im Mittelstand begegnet

• Onlineshops: Mehrere verbreitete Shopsysteme stellen ihre Produktdaten per GraphQL bereit. Wer den Shop mit Warenwirtschaft oder PIM-System verbindet, arbeitet dann mit dieser Schnittstelle.
• Headless-Websites: Ein Headless-CMS liefert Inhalte per GraphQL an Website und App, und jede Seite holt nur die Felder, die sie anzeigt.
• Außendienst-Apps: Eine App für Vertrieb oder Service braucht unterwegs wenige, aber verknüpfte Daten: Kunde, offene Angebote, letzte Wartung. Mit GraphQL lädt sie das in einem Aufruf, was bei schwachem Mobilfunk spürbar schneller ist als mehrere Einzelabfragen.
• Kundenportale: Ein Portal zeigt Aufträge, Rechnungen und Tickets aus drei Systemen. Eine GraphQL-Schicht davor bündelt sie zu einer Sicht.

Grenzen und Risiken

• Teure Abfragen: Weil der Client frei kombinieren darf, kann eine einzige verschachtelte Anfrage den Server stark belasten. Tiefenbegrenzung, Kostenbewertung und Zeitlimits gehören daher zu jeder öffentlichen GraphQL-API.
• Zugriffsrechte je Feld: Rechte müssen auf Feldebene geprüft werden, nicht nur am Eingang. Sonst sieht ein Kunde im Portal plötzlich die Einkaufspreise.
• Fehlerbilder: GraphQL antwortet oft mit HTTP-Status 200, auch wenn Teile der Anfrage fehlschlagen. Monitoring muss den Inhalt der Antwort auswerten.
• Aufwand: Ein gutes Schema will durchdacht sein. Für eine einzelne Integration ist das häufig mehr Arbeit, als sie wert ist.

In der Praxis: Schnittstellen, die zu Ihren Systemen passen

Ob REST, GraphQL oder Dateiaustausch – wir wählen die Technik nach dem, was Ihre vorhandenen Programme anbieten. Bei der Systemintegration binden wir GraphQL-Schnittstellen von Shops und SaaS-Diensten an ERP, CRM und Buchhaltung an und überwachen jede Verbindung. Wenn Sie ein eigenes Portal oder eine App mit vielen Datenquellen planen, entsteht die passende API im Rahmen einer Web-Anwendung.

Häufige Fragen

Ist GraphQL eine Datenbank?

Nein. GraphQL ist eine Sprache für Schnittstellen. Die Daten können in jeder Datenbank oder in anderen Diensten liegen; GraphQL beschreibt nur, wie man sie abfragt.

Ersetzt GraphQL REST?

Nicht grundsätzlich. Viele Anbieter betreiben beide Varianten nebeneinander. GraphQL ist eine Alternative für bestimmte Anwendungsfälle, vor allem bei vielen Oberflächen mit unterschiedlichem Datenbedarf.

Welche Werkzeuge braucht man für GraphQL?

Für fast jede verbreitete Programmiersprache gibt es ausgereifte Bibliotheken für Server und Client. Zum Ausprobieren eignen sich grafische Abfrage-Oberflächen, die das Schema lesen und beim Schreiben der Anfrage Felder vorschlagen. Für den produktiven Betrieb kommen Monitoring und eine Begrenzung der Abfragekosten hinzu.

Ist GraphQL sicher?

So sicher wie seine Umsetzung. Authentifizierung, Rechte je Feld, Begrenzung der Abfragetiefe und das Abschalten der offenen Schema-Abfrage in öffentlichen Umgebungen gehören zum Pflichtprogramm.