Mit GraphQL den Überblick über die Daten behalten

Daten werden über APIs abgefragt und verändert. Der bekannteste Ansatz dafür ist REST: Jede Ressource ist unter einer bestimmten Adresse zu finden. Doch je komplexer dein digitales Produkt, desto komplexer die Daten – und desto mehr Adressen, die immer mehr Daten liefern müssen, um alle Bedürfnisse abzudecken.

Eine Antwort darauf bietet GraphQL: Bei jeder Abfrage wird spezifiziert, welche Daten benötigt werden; so kann der Datenaustausch unter einer Adresse gebündelt werden, ohne an Übersichtlichkeit zu verlieren.

Stell dir vor, du bist im Detailhandel tätig.

Dein Katalog umfasst tausende Produkte, die du im Internet präsentierst. Alle können von User*innen bewertet werden. Die Bewertungen können kommentiert und gelikt werden. Diese Beiträge werden dann in deiner App, der Community-Plattform und der Produkte-Übersicht dargestellt.

Dafür hantierst du bereits 3 Typen von Daten: User, Produkte und Beiträge. Sie haben je ihre eigene Datenstruktur und sie stehen zueinander in Beziehung. In der App willst du die Beiträge zu einem Produkt darstellen, auf der Community die Beiträge pro Benutzer*in.

Erschwerend kommt hinzu, dass für User- und Produktdaten bereits REST-APIs bestehen. Also noch eine REST-API für die Userbeiträge hochziehen? Toll wäre eine Technologie, die mächtig ist und die Komplexität trotzdem nicht erhöht. Vorhang auf für GraphQL.

GraphQL: Die maximal flexible API

GraphQL ist geschaffen für flexiblen Datenaustausch – inklusive besserem Überblick, da alle Daten typisiert sind. Das macht es zu einer leistungsfähigen Alternative zu REST.

Das GraphQL-Schema ist der «Masterplan»: Es definiert die Datenstruktur und garantiert, dass die Daten in einer bestimmten Form ausgeliefert werden. Wer weiss, was zu erwarten ist, muss sich nicht mit fehlenden Daten und daraus resultierenden Bugs rumschlagen. Aus dem Schema lassen sich ganz einfach Types generieren, die in TypeScript verwendet werden können. Das macht Entwickler*innen froh und das wiederum das Produkt besser.

Vermeidet Under- und Overfetching

Clients definieren, welche Daten sie benötigen, und erhalten genau diese zurück – und nicht noch fünf Produkte und zwölf Beiträge, die gar nirgends angezeigt werden (Overfetching). Dafür angereichert mit allen User-Angaben, die bei REST separat abgeholt werden müssten (Underfetching).

Ermöglicht schnelle Weiterentwicklung

Weil jeder Client bei der Abfrage die benötigten Daten definiert, kann die API mit minimalem Aufwand neue Anwendungsfälle bedienen: Alle Beiträge, die in den letzten 7 Tagen verfasst wurden? Kein Problem. Alle Kommentare zu einem Produkt und gleich noch die Namen aller, die sie gelikt haben? Nichts leichter als das. Oder nur die Kommentare mit Likes? Aber gern!

Macht Versionierung unnötig

GraphQL-APIs können neue Bedürfnisse bedienen und bleibt trotzdem rückwärtskompatibel, da die gewünschte Datenstruktur in jedem Client definiert wird. Dies im Gegensatz zu REST-APIs, wo Änderungen an der Datenstruktur eine Versionierung nötig macht, um sicherzustellen, dass bestehende Clients nicht mit Daten in unbekannter Form konfrontiert sind.

Caching? Klar doch!

Maximale Flexibilität geht nicht auf Kosten der Leistung: Auch bei GraphQL können ressourcenintensive Abfragen gecacht werden. Bei Änderung der Daten wird der Cache wieder gelöscht. Damit sehen Benutzer*innen jederzeit die aktuellste Daten – zuverlässig und schnell.

Unsere Erfahrung

Unsere Community-Plattform Reactions setzt auf GraphQL. Beim Aufbau haben wir eine Menge Knowhow gesammelt – und darüber gebloggt: Building Enterprise Grade APIs with GraphQL, MySQL and Node.js. Und auch in Kombination mit Elasticsearch haben wir GraphQL schon eingesetzt: GraphQL and Elasticsearch: A Love Letter.

Hier steckt GraphQL drin: