Stell dir vor, du bist im Detailhandel tätig.
Dein Katalog umfasst tausende Produkte, die du im Internet präsentierst. Alle können von Userinnen 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 TypeScriptverwendet 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
