GraphQL
GraphQL ist eine Abfragesprache und Laufzeitumgebung für Schnittstellen (APIs), mit der ein Client über einen einzigen Endpunkt exakt die Daten anfragt, die er braucht – nicht mehr und nicht weniger. Im ERP-Umfeld verbindet GraphQL das ERP-System mit Shop, App und Drittsystemen und reduziert dabei überflüssige Datenübertragung.
GraphQL ist eine 2015 von Facebook (heute Meta) veröffentlichte Abfragesprache für Schnittstellen (APIs) sowie die dazugehörige serverseitige Laufzeitumgebung. Das Besondere: Ein aufrufendes Programm (Client) beschreibt in seiner Anfrage genau, welche Felder es zurückhaben will, und der Server liefert exakt diese Struktur zurück – über einen einzigen Endpunkt, statt über viele feste Adressen wie bei klassischen Web-APIs. So entscheidet der Client, nicht der Server, wie viel und welche Daten fließen.
Im ERP- und E-Commerce-Umfeld ist GraphQL eine von mehreren Techniken, mit denen sich ein Warenwirtschafts- oder ERP-System an Onlineshops, Apps, Portale und Drittsysteme anbinden lässt. Gegenüber dem verbreiteten REST-Stil verspricht GraphQL vor allem, dass eine App in einer einzigen Abfrage mehrere zusammenhängende Objekte – etwa einen Auftrag samt Kunde, Positionen und Lagerbeständen – abholen kann, ohne dafür mehrere Anfragen zu stellen oder überflüssige Felder mitzuschleppen. Das macht GraphQL besonders für datenhungrige Frontends und mobile Anwendungen attraktiv.
Auf einen Blick
- GraphQL = Abfragesprache + Laufzeit für APIs; Client bestimmt die Antwortstruktur
- Ein einziger Endpunkt statt vieler URLs wie bei REST
- Schema mit Typen definiert verbindlich, welche Daten und Felder es gibt
- Kein Over-Fetching / Under-Fetching: es kommt genau das Angefragte zurück
- Alternative bzw. Ergänzung zu REST-API, SOAP und Webhooks für die ERP-Integration
Wie GraphQL funktioniert: ein Schema, ein Endpunkt
Herzstück jeder GraphQL-Schnittstelle ist das Schema. Es beschreibt in einer eigenen Typsprache, welche Objekte es gibt (etwa Kunde, Auftrag, Artikel), welche Felder diese Objekte besitzen und wie sie zusammenhängen. Das Schema ist ein verbindlicher Vertrag zwischen Server und Client: Jede Anfrage wird gegen dieses Schema geprüft, und Werkzeuge können daraus automatisch Dokumentation und Autovervollständigung erzeugen. Für Entwickler wirkt eine GraphQL-API dadurch oft wie eine selbsterklärende Landkarte der verfügbaren Daten.
Anders als bei REST spricht ein Client nicht viele verschiedene Adressen an, sondern schickt alle Anfragen an einen einzigen Endpunkt. In der Anfrage steht eine Abfrage (Query), die exakt die gewünschten Felder auflistet – zum Beispiel „gib mir von diesem Auftrag die Auftragsnummer, den Kundennamen und alle Positionen mit Artikelnummer und Menge“. Der Server antwortet mit einem JSON-Objekt, dessen Struktur der Anfrage entspricht. Fehlt ein Feld in der Anfrage, taucht es auch in der Antwort nicht auf.
Query, Mutation und Subscription
GraphQL kennt drei Operationstypen. Eine Query liest Daten (vergleichbar mit einem GET bei REST). Eine Mutation verändert Daten – legt also etwa einen Kunden an, ändert einen Bestand oder storniert einen Auftrag. Eine Subscription schließlich abonniert Ereignisse: Der Server schickt dem Client aktiv eine Nachricht, sobald sich etwas ändert, etwa wenn ein neuer Auftrag eingeht. Damit deckt GraphQL sowohl das klassische Frage-Antwort-Muster als auch Echtzeit-Benachrichtigungen ab.
GraphQL vs. REST: der zentrale Unterschied
Der wichtigste Unterschied zwischen GraphQL und der REST-API betrifft die Frage, wer die Antwort bestimmt. Bei REST definiert der Server für jede Ressource eine feste Adresse mit einer festen Antwortstruktur; der Client bekommt, was diese Adresse liefert. Das führt in der Praxis oft zu zwei Problemen: Over-Fetching, wenn eine Adresse deutlich mehr Felder zurückgibt als benötigt, und Under-Fetching, wenn für eine Ansicht mehrere Adressen nacheinander abgefragt werden müssen. GraphQL löst beides, weil der Client die gewünschten Felder selbst zusammenstellt und zusammenhängende Objekte in einer einzigen Abfrage erhält.
Dafür verschiebt GraphQL Komplexität auf den Server und ins Caching. REST profitiert davon, dass jede Adresse über Standard-Mechanismen des Webs (HTTP-Caching, Statuscodes) leicht zwischenspeicherbar ist; bei GraphQL mit seinem einen Endpunkt und beliebigen Abfragen ist das aufwendiger. Zudem lässt sich mit einer verschachtelten GraphQL-Abfrage theoretisch sehr viel auf einmal anfordern, was Server belasten kann. In der Praxis ist GraphQL daher kein „besseres REST“, sondern eine Alternative mit anderem Zuschnitt – viele Systeme bieten beides an, und die Wahl hängt vom Anwendungsfall ab.
GraphQL im ERP-System
Für die ERP-Integration ist GraphQL vor allem dort interessant, wo ein Frontend viele verknüpfte Daten kompakt braucht. Ein Kundenportal, eine Außendienst-App oder ein individuell gebautes Shop-Frontend (Headless Commerce) kann mit einer Abfrage Auftragskopf, Positionen, Kundenstammdaten und aktuelle Verfügbarkeiten holen, statt mehrere REST-Aufrufe zu bündeln. Das reduziert die übertragene Datenmenge und die Zahl der Rundreisen zwischen App und ERP – ein spürbarer Vorteil auf mobilen Geräten und bei großen Objektmengen.
Nicht jedes ERP bietet eine GraphQL-Schnittstelle; viele setzen weiterhin primär auf REST-APIs, SOAP oder EDI, teils ergänzt durch Webhooks für Echtzeit-Ereignisse. Wer ein System auswählt, sollte GraphQL daher nicht als Selbstzweck betrachten, sondern fragen, ob die vorhandene Schnittstelle die benötigten Objekte lesend und schreibend abdeckt und gut dokumentiert ist. Große Plattformen im E-Commerce – etwa Shopify – haben GraphQL zum bevorzugten API-Zugang gemacht, weshalb Anbindungen an solche Kanäle in der Praxis häufig über GraphQL laufen.
Wann sich GraphQL für die Anbindung lohnt
Als Faustregel lohnt sich GraphQL, wenn ein maßgeschneidertes Frontend viele verschachtelte Daten braucht und die Datenmenge oder die Antwortzeit kritisch ist. Für einfache, klar abgegrenzte Server-zu-Server-Prozesse – etwa den nächtlichen Abgleich von Belegen mit der Finanzbuchhaltung – bleibt eine schlanke REST-API oder ein fest definiertes Datenformat oft die pragmatischere Wahl. Entscheidend ist nicht die Modernität der Technik, sondern die Passung zum Prozess.
Vorteile, Grenzen und typische Fallstricke
Die Stärken von GraphQL liegen in Flexibilität und Präzision: Clients bekommen exakt die Daten, die sie brauchen, das Schema dient als lebende Dokumentation, und neue Felder lassen sich hinzufügen, ohne bestehende Abfragen zu brechen – ein Grund, warum GraphQL selten harte Versionsnummern wie „v2“ benötigt. Für Teams, die schnell wechselnde Oberflächen bauen, verkürzt das die Abstimmung zwischen Frontend und Backend erheblich.
Die Grenzen sind ebenso real. Caching ist aufwendiger als bei REST, die Absicherung gegen zu komplexe oder tief verschachtelte Abfragen erfordert zusätzliche Schutzmechanismen (etwa Tiefen- und Kostenlimits), und für sehr einfache Schnittstellen ist GraphQL überdimensioniert. Auch die Fehlerbehandlung unterscheidet sich: GraphQL liefert häufig den HTTP-Status 200 und meldet Fehler im Antwortkörper, was Monitoring-Konzepte anpassen muss. Wer GraphQL einführt, sollte diese Punkte von Anfang an mitplanen, statt sie später nachzurüsten.
Praxisbeispiel
Beispiel: Außendienst-App eines B2B-Großhändlers
Ein mittelständischer Großhändler stattet seinen Außendienst mit einer Tablet-App aus, die beim Kundenbesuch offene Aufträge, Kontaktdaten und aktuelle Lagerbestände zeigt. Über eine klassische REST-API müsste die App pro Kunde mehrere Adressen nacheinander abfragen: eine für die Stammdaten, eine für die Aufträge, je eine für die Artikelverfügbarkeiten. Bei schlechter Mobilfunkverbindung dauert das spürbar und überträgt viele Felder, die niemand sieht.
Mit einer GraphQL-Schnittstelle stellt die App eine einzige Abfrage, die genau Kundenname, offene Auftragsnummern, Positionen und die aktuelle Verfügbarkeit je Artikel anfordert. Das ERP liefert exakt dieses Paket zurück. Die App lädt schneller, verbraucht weniger Datenvolumen, und wenn das Team später ein Feld wie „letztes Lieferdatum“ ergänzen will, genügt es, dieses Feld in die Abfrage aufzunehmen – ohne dass die Schnittstelle umgebaut werden muss.
Häufige Fragen
Passende Leistungen
Fragen zu GraphQL in deinem ERP-Projekt?
Wir beraten herstellerunabhängig – und setzen es auf Wunsch selbst um.