GraphQL – moderne API-Abfragesprache
GraphQL ist eine offene Abfragesprache und eine zugehörige Laufzeitumgebung für Programmierschnittstellen (APIs), mit der eine aufrufende Anwendung exakt beschreibt, welche Daten sie benötigt, und genau diese Datenmenge in einer einzigen Antwort zurückerhält. Ursprünglich 2012 bei Facebook entwickelt und 2015 als offener Standard veröffentlicht, wird GraphQL heute auch als Integrationsschicht über ERP-Systeme gelegt.
Im Gegensatz zu klassischen Schnittstellen, bei denen jede Ressource über eine eigene Adresse bereitgestellt wird, arbeitet GraphQL mit einem typisierten Schema und einem zentralen Endpunkt. Das macht die Sprache besonders interessant für moderne ERP-Architekturen, in denen viele unterschiedliche Oberflächen und Dienste auf dieselben Stammdaten zugreifen.
- Begriff
- GraphQL
- Entitätstyp
- Technologie / API-Standard
- Domäne
- IT-Integration und Schnittstellen
- Kanonische Definition
- GraphQL ist eine offene Abfragesprache und Laufzeitumgebung für APIs, mit der ein Client über ein typisiertes Schema und einen einzigen Endpunkt präzise festlegt, welche Datenfelder er benötigt und zurückerhält.
- Einordnung
- GraphQL ist ein Schnittstellenstil und ordnet sich dem übergeordneten Konzept der API unter; es steht als Alternative neben der REST-API.
- Verwandte Begriffe
- API, REST-API, EDI vs. API, Headless-ERP, Composable-ERP, API-First-ERP
- Quelle
- erp-software.org Redaktion (unabhängig, anbieterneutral)
Was GraphQL NICHT ist — Abgrenzung
- Keine Datenbank: GraphQL speichert selbst keine Daten; die Persistenz bleibt bei der ERP-Datenbank oder den nachgelagerten Diensten.
- Kein ERP-System: GraphQL ersetzt weder die fachliche Geschäftslogik noch ein vollständiges ERP, sondern stellt nur den Datenzugriff bereit.
- Kein REST-Ersatz per se: GraphQL ist nicht grundsätzlich besser als REST, sondern eine alternative Schnittstellensicht mit anderen Stärken und Kompromissen.
- Kein reines Frontend-Werkzeug: GraphQL ist eine Server- und Client-übergreifende Spezifikation, keine Bibliothek nur für Benutzeroberflächen.
Funktionsweise und Grundprinzip
GraphQL beruht auf einem stark typisierten Schema, das alle verfügbaren Datenobjekte, Felder und Beziehungen beschreibt. Dieses Schema fungiert als Vertrag zwischen Anbieter und Abnehmer der Daten: Der Client kann nur das abfragen, was das Schema deklariert. Eine Abfrage ähnelt dabei strukturell dem gewünschten Ergebnis. Fordert eine Anwendung etwa zu einem Kundenauftrag die Auftragsnummer, das Lieferdatum und die Positionen mit Artikelbezeichnung an, liefert die Antwort exakt diese Felder, weder mehr noch weniger.
Damit adressiert GraphQL zwei typische Probleme klassischer Schnittstellen: das sogenannte Overfetching (es werden mehr Daten übertragen als gebraucht) und das Underfetching (für eine Maske sind mehrere Aufrufe nötig). Über die Verschachtelung von Feldern lassen sich zusammenhängende Objekte wie Auftrag, Kunde und Artikel in einem einzigen Aufruf laden, was die Zahl der Anfragen reduziert.
Bestandteile und Ablauf einer Abfrage
Technisch unterscheidet GraphQL drei Operationstypen. Queries dienen dem Lesen von Daten, Mutations verändern Daten, etwa beim Anlegen oder Aktualisieren eines Datensatzes, und Subscriptions ermöglichen ereignisgesteuerte Aktualisierungen, beispielsweise bei einer Bestandsänderung im Lager. Eine Anfrage wird in der Regel als HTTP-Aufruf an einen einzigen Endpunkt gesendet und vom Server gegen das Schema validiert.
Auf Serverseite löst eine Logik, oft als Resolver bezeichnet, jedes angeforderte Feld auf und holt die Werte aus den dahinterliegenden Quellen, etwa der ERP-Datenbank, einem nachgelagerten Dienst oder einer bestehenden REST-API. Dadurch lässt sich GraphQL auch als vereinheitlichende Schicht über mehrere Systeme legen, ohne deren interne Struktur preiszugeben.
Relevanz im ERP-Kontext
ERP-Systeme verwalten umfangreiche, stark vernetzte Datenmodelle: Stammdaten, Belege, Buchungen und Bewegungsdaten hängen über viele Beziehungen zusammen. Genau hier spielt GraphQL eine Stärke aus, weil verschachtelte Objekte gezielt und in einem Aufruf abgerufen werden können. In Architekturen mit entkoppelten Oberflächen, etwa bei einem Headless-ERP oder einem Composable-ERP, dient GraphQL häufig als flexible Datenzugriffsschicht für Web-Portale, mobile Apps und Partner-Anbindungen.
Als ein Schnittstellenstil ordnet sich GraphQL in das übergeordnete Konzept der API ein und konkurriert beziehungsweise ergänzt etablierte Ansätze. Während REST über viele Endpunkte arbeitet, bündelt GraphQL den Zugriff über ein Schema. Die Wahl hängt vom Anwendungsfall ab und wird im Detail unter EDI vs. API sowie in der Abgrenzung verschiedener Integrationsmuster diskutiert.
Praxisbeispiel
Ein Hersteller betreibt ein Kundenportal, in dem Geschäftspartner Auftragsstatus, Liefertermine und offene Rechnungen einsehen. Über eine REST-Schnittstelle müsste das Portal mehrere getrennte Aufrufe absetzen, einen für den Auftragskopf, einen für die Positionen und einen für den Rechnungsstatus. Mit GraphQL formuliert die Anwendung eine einzige Abfrage, die genau die für die Portalansicht benötigten Felder über alle drei Bereiche zusammenführt. Das senkt die Übertragungsmenge und vereinfacht die Frontend-Entwicklung, weil neue Felder ohne neue Endpunkte ergänzt werden können. Anbieter aus dem ERP-Umfeld stellen GraphQL teils nativ bereit, teils über vorgelagerte Integrationsplattformen.
Auswahl- und Umsetzungshinweise
Beim Einsatz von GraphQL in ERP-Projekten sind einige Punkte zu beachten. Erstens erfordert der flexible Zugriff ein durchdachtes Berechtigungs- und Rollenkonzept, da Clients über tief verschachtelte Abfragen potenziell viele Datenobjekte erreichen könnten. Zweitens kann eine einzelne komplexe Abfrage erhebliche Last erzeugen, weshalb Tiefenbegrenzungen, Komplexitätsanalysen und Zwischenspeicherung üblich sind. Drittens sollte das Schema als langlebiger Vertrag versioniert und gepflegt werden, weil viele Abnehmer davon abhängen.
Für die Praxis empfiehlt sich, die Verfügbarkeit einer GraphQL-Schnittstelle im Lasten- und Pflichtenheft zu prüfen und zu klären, ob der Anbieter sie nativ bereitstellt oder über eine zusätzliche Integrationsschicht. Sicherheits-, Protokoll- und Nachvollziehbarkeitsanforderungen, etwa über einen Audit-Trail, gelten für GraphQL ebenso wie für andere Schnittstellen.
Abgrenzung
GraphQL ist kein eigenes ERP-System und kein Ersatz für die fachliche Geschäftslogik, sondern ein Zugriffs- und Abfragemechanismus auf vorhandene Daten. Es ist auch keine Datenbank, obwohl die Sprache wie eine Abfragesprache wirkt; die eigentliche Speicherung übernehmen weiterhin die dahinterliegenden Systeme. Schließlich ist GraphQL nicht zwingend besser als REST, sondern eine alternative Sichtweise auf den Datenzugriff mit anderen Stärken und Kompromissen.
Verwandte Themen
Häufig gestellte Fragen
Sollte ich GraphQL oder REST nutzen?
Bei einfachen Integrationen REST. Bei komplexen Frontends mit vielen Datenquellen GraphQL.
In der Praxis variiert die genaue Ausgestaltung je nach Branche, Größenklasse und Customizing-Tiefe des konkreten ERP-Setups.
Performt GraphQL besser als REST?
Nicht automatisch. Über-aggressive GraphQL-Queries können Server überlasten. Pro Use Case bewerten.
