Spring GDS 25. Jubiläum
Ein Logistikunternehmen, das in 190 Länder versendet, hat etwas gebaut, um an sich selbst zu liefern.
GraphQL ist eine Abfragesprache für APIs und eine Laufzeitumgebung zum Ausführen dieser Abfragen, von Meta entwickelt und 2015 als Open Source freigegeben. Es bietet eine Alternative zu REST, indem es Clients genau die Daten anfragen lässt, die sie brauchen, nicht mehr und nicht weniger.
Der Unterschied zu REST ist struktureller Natur. In einer REST-API liefert jeder Endpunkt eine feste Form, sodass alles zu bekommen, was eine Ansicht braucht, oft heißt, mehrere Endpunkte anzusprechen und Teile jeder Antwort zu verwerfen. GraphQL stellt in der Regel einen einzigen Endpunkt bereit, und der Client beschreibt die Form der Antwort innerhalb der Abfrage selbst. Das beseitigt Over-Fetching, bei dem Sie Daten erhalten, die Sie nie nutzen, und Under-Fetching, bei dem eine Anfrage nicht reicht. Eine mobile Ansicht, die Namen, die letzten drei Bestellungen und Treuepunkte eines Nutzers zeigt, kann genau diese Felder in einem Roundtrip holen statt in dreien. Darunter liegt ein stark typisiertes Schema, das die API dokumentiert und Tooling wie Autovervollständigung und Validierung antreibt, und es lässt die API durch das Hinzufügen von Feldern wachsen, ohne die Abfragen zu brechen, auf die sich Clients bereits verlassen.
GraphQL verdient sich seinen Platz bei Produkten mit komplexen, vernetzten Daten oder mehreren Clients, die ein Backend nutzen. Eine Web-App, eine Mobile-App und eine Partner-Integration können jeweils denselben Graphen nach dem Ausschnitt abfragen, den sie brauchen, was schwerer zu koordinieren ist, wenn jeder Client von festen REST-Antworten abhängt.
Wenn ein Produkt reichhaltige Daten und mehr als einen Client hat, der daraus zieht, ist GraphQL oft das sauberere Fundament. Wir greifen dort dazu, wo ein einziger, gut typisierter Graph einer Web-App und einer Mobile-App erspart, jeweils eigene Endpunkte auszuhandeln, und wo das Schema zur lebenden Dokumentation wird, der das ganze Team vertraut.
Es passt dazu, wie wir API-Integration und einen API-First-Build angehen, bei dem der Vertrag zwischen Backend und Frontend früh festgelegt und eingehalten wird. Diese Disziplin lässt Kunden später neue Oberflächen hinzufügen, eine Partner-Integration oder eine neue App, ohne die darunterliegende Schicht neu zu schreiben.
Haben Sie Daten, die mehrere Apps speisen, und genug von wuchernden Endpunkten? Entwerfen wir den Graphen.
Ein Logistikunternehmen, das in 190 Länder versendet, hat etwas gebaut, um an sich selbst zu liefern.
Eine Marke in ein funktionierendes Geschäft verwandeln.
Eine halbe Million Menschen. Eine App. Null Chaos.















