GraphQL
GraphQL ist eine Sprache, mit der eine App bei einem Server genau die Daten anfordert, die sie gerade braucht — nicht mehr und nicht weniger. Sie wurde 2012 bei Facebook entwickelt und ist heute eine verbreitete Alternative zum klassischen REST-Ansatz.
Fast jede App holt sich ihre Inhalte von einem fremden Computer im Internet, dem Server. Dafür muss sie ihm mitteilen, welche Daten sie haben will. GraphQL ist eine festgelegte Sprache für genau solche Anfragen. Die App schickt eine Art Bestellzettel, auf dem die gewünschten Felder stehen, etwa Name, Profilbild und die letzten fünf Beiträge. Der Server antwortet mit exakt diesen Feldern, in derselben Struktur. Entwickelt wurde das Verfahren 2012 bei Facebook, seit 2015 darf es jeder frei benutzen.
Warum das Datenholen sonst so umständlich ist
Bis GraphQL kam, war REST der übliche Weg. Dort gibt es für jede Art von Information eine eigene Adresse. Eine Adresse liefert Nutzerdaten, eine andere die Beiträge, eine dritte die Kommentare. Der Server bestimmt dabei, was in der Antwort steht. Die App muss nehmen, was kommt.
Daraus entstehen zwei typische Probleme. Beim ersten bekommt die App zu viel: Sie braucht nur den Namen, erhält aber das komplette Profil mit fünfzig Feldern. Beim zweiten bekommt sie zu wenig und muss nacheinander mehrere Anfragen stellen. Für eine Übersichtsseite können so schnell zehn Anfragen nötig werden.
Im Handynetz ist das spürbar. Jede zusätzliche Anfrage kostet Wartezeit, überflüssige Daten kosten Datenvolumen und Akku. Genau dieses Problem hatte Facebook mit seiner mobilen App, als GraphQL entstand. Eine einzige, präzise Anfrage ist dort deutlich schneller als viele ungenaue.
Schema, Abfrage und Resolver
Grundlage ist das Schema. Darin steht verbindlich, welche Datentypen es gibt und welche Felder dazugehören. Ein Typ « Nutzer » hat zum Beispiel die Felder Name, E-Mail und Beiträge. Das Schema ist gleichzeitig die Dokumentation der Schnittstelle. Entwicklungswerkzeuge lesen es aus und schlagen beim Tippen passende Felder vor.
Die eigentliche Abfrage sieht aus wie ein Gerüst aus geschweiften Klammern ohne Inhalt. Man schreibt hinein, welche Felder man will, und darf verschachteln: zum Nutzer seine Beiträge, zu jedem Beitrag die Kommentare. Der Server liefert die Antwort in genau derselben Form zurück. Das macht das Ergebnis für Entwickler gut vorhersehbar.
Auf der Serverseite steckt hinter jedem Feld ein kleines Programmstück, der Resolver. Es weiß, woher der Wert kommt — aus einer Datenbank, aus einem anderen Dienst oder aus einer Berechnung. Ein Vorteil dabei: Die Adresse im Netz bleibt immer dieselbe, meist endet sie auf /graphql. Ein Nachteil: Eine tief verschachtelte Abfrage kann den Server stark belasten, deshalb begrenzen Betreiber die erlaubte Verschachtelungstiefe.
Wo GraphQL im Netz und in KI-Produkten steckt
Sichtbar ist die Technik selten, benutzt wird sie ständig. GitHub, Shopify und die Entwicklerschnittstellen vieler großer Plattformen bieten GraphQL an. Wer eine Online-Shop-Seite öffnet, löst im Hintergrund oft genau solche Abfragen aus. Auch Streaming-Dienste und soziale Netzwerke setzen darauf, weil ihre Oberflächen viele verschiedene Datenstücke gleichzeitig zeigen.
Interessant ist der Begriff inzwischen auch im KI-Umfeld. Sprachmodelle sollen zunehmend selbst Daten abrufen, statt nur aus dem Gedächtnis zu antworten. Ein Schema, das jedes verfügbare Feld klar benennt, hilft einem Modell dabei, eine korrekte Abfrage zu formulieren. Manche Unternehmen legen deshalb bewusst GraphQL-Schnittstellen an, bevor sie KI-Assistenten auf ihre Daten loslassen.
Ein häufiger Irrtum: GraphQL sei eine Datenbank. Das stimmt nicht. Es ist nur die Sprache zwischen App und Server, die Daten liegen weiterhin in ganz normalen Datenbanken. Und GraphQL ersetzt REST nicht überall — für einfache Schnittstellen mit wenigen Feldern bleibt der ältere Ansatz oft die schlankere Wahl.