123 Invest Gruppe: Kommentar
GraphQL ist flexibler, das Ende von REST APIs?
Bisher wurde die Brücke zwischen Frontend und Backend meist durch eine REST Schnittstelle gelöst, um eine Kommunikation zwischen zwei Systemen oder Prozessen zu realisieren. Nun arbeiten moderne Softwaressysteme mit immer komplexer werdenden Daten und Regeln, die Flexibilität erfordern. Dies beeinflusst auch die Kommunikation zwischen den Schnittstellen. Jetzt gibt es eine Alternative. Wird sich GraphQL als Alternative zu REST etablieren und den angekündigten flexiblen Datenumgang zur Verfügung stellen?
Fakt ist: Bei GraphQL – kurz für Graph Query Language – handelt es sich um eine Abfragesprache, die von Facebook im Jahr 2012 für APIs entwickelt wurde und die nach ausgiebiger interner Verwendung im Jahr 2015 erstmalig erschienen ist.
Das API-Design nach REST
Das ursprüngliche API Design nach REST hat sich vor allem in Singlepage-Anwendungen etabliert, da es sich hier besonders gut nutzen und verstehen lässt. Doch perspektivisch hat dieses Prinzip einige Nachteile, wodurch es nur in Ausnahmefällen konsequent durchgehalten wird.
Im folgenden Beispiel möchten wir Ihnen die Herausforderungen dieses Ansatzes verdeutlichen.
Wir stellen uns vor, dass es sich beim Client um eine Person namens „Hanna“ handelt. Hanna ist gerne zu Hause und isst Pizza Margherita aus einem Restaurant. Sie bestellt ihr Waschmittel vom Supermarkt und beauftragt REST, ihr diese Produkte zu beschaffen. REST kann nicht alle Wege mit einem Mal gehen, weshalb Hanna die Pizza Margherita in den Fokus nimmt und von REST den Inhalt der gesamten Menükarte erhält. Hanna isst und beauftragt REST nun damit, das im Supermarkt erhältliche Waschmittel zu organisieren. Doch auch bei diesem Auftrag bringt er das ganze Sortiment und nicht nur die Bestellung mit.
Für Hanna ergeben sich folgende Nachteile:
Sie erhält immer mehr als bestellt, da REST nur feste Datenstrukturen liefern kann.
Hanna muss ihre Wünsche einzeln und nacheinander äußern, da die Endadresse nicht identisch und eine parallele Bestellung unmöglich ist.
Beim Overfetching liefert der Client zahlreiche Daten, die er selbst gesucht und ausgewählt hat. So kommt es zu unerwünschten Daten (in Hannas Fall Lieferungen), die unnötig Zeit kosten und den Speicher füllen.
Das Gegenteil, das Unterfetching basiert darauf, dass REST nicht parallel über mehrere Endpunkte hinaus einsetzbar ist. Daher entsteht ein höherer Zeitaufwand, um alle Bestellungen nacheinander aufzugeben. Würde sich Hanna nur auf das Restaurant konzentrieren, käme zwar die Pizza, doch auf das Waschmittel würde sie vergeblich warten.
Dieses Szenario ist Vergangenheit. Mit dem entsprechenden API-Design sind beide Probleme gleichzeitig lösbar. Die REST APIs sprechen eine mächtige Sprache, die mit einem präzisen Ausdruck einhergeht und so nicht mehr das gesamte Restaurant zu Hanna liefert.
Hinzu kommt, dass der Client dem Server ein interpretierbares Zeichen gibt. So werden die Supermarktprodukte innerhalb der Datenbank durch EAN-Codes gekennzeichnet, während die bestellte Pizza eine andere Markierung aufweist. Damit Hanna nur die Bestellung und keine zusätzlichen Produkte bekommt, wird die REST API in codierter Form an den Server geschickt und zur Datenbank übertragen. Ist ein Produkt nicht mehr erhältlich, bekäme Hanna eine Fehlermeldung und nicht automatisch ein „alternatives“ Produkt.
Auch für Hanna ergeben sich einige Veränderungen. Um ein detailliertes Ergebnis zu erzielen, muss sie bei REST eine detaillierte Beschreibung zur Übertragung an den Server abgeben. Die Endpunkte können sich wie folgt gestalten: URL/api/supermarkt/produkte/{ean}
URL/api/restaurant/pizza/margherita /api/supermarkt
In diesem Fall bekommt Hanna nur die Margherita-Pizza und nicht die gesamte Menükarte. Durch die Designlösung lassen sich Over- und Underfetching ausschließen. Doch wenn sie nicht nur eine, sondern mehrere verschiedene Pizzen bestellen möchte, würde Hanna nach wie vor mehrere API Aufrufe nacheinander tätigen. Anders als im Supermarkt, greift die Pizzeria nicht auf EANs zurück. Eine alternative Ressourcenidentifizierung ist essenziell. Auch bei mehreren Produkten aus verschiedenen Bereichen wären mehrere REST-Endpunkte wichtig. Wenn Hanna also mehr Ressourcen aus dem Backend wünscht, muss sie mehr Endpunkte eingeben und steht letztendlich wieder vor ihrem bekannten Problem.
GraphQL – Eine Lösung für Hanna?
Facebook hat sich diesen Herausforderungen bereits im Jahr 2012 gestellt und GraphQL entwickelt. Drei Jahre lang wurde die Option intern getestet, ehe sie im Jahr 2015 an die Öffentlichkeit gelangte. Heute wird sie von einem vollständigen Ökosystem umschlossen, das analog zum Standard REST viele Projekte unterstützt. Es gibt viele gravierende Besonderheiten, die im Vergleich zu anderen API-Designs den Unterschied machen und den Herausforderungen von REST mit einer völlig neuen Antwort begegnen.
Ein Endpunkt für Alles
Das Geheimnis bei GraphQL ist der Single Endpunkt. Das heißt konkret, dass es für alle Anforderungen nur einen Endpunkt gibt und das nur eine Query an den Endpunkt versandt werden muss. Die Query-Sprache ist SQL, also eine Sprache, die vom Server direkt interpretiert wird. Wenn Hanna die Query URL url/graphql?query=hannaswuensche eingibt, kann sie alle Wünsche definieren, die ihr am Herzen liegen.
Ein Wrapper für GraphQL
GraphQL ist optional als Wrapper verfügbar. Das heißt, dass alle Ressourcen angelegt und zum Beispiel für verschiedene Server – und Datenbanken verteilt werden sollen. Siehe Hannas Bestellung im Restaurant und im Supermarkt.
Übersichtlichkeit im Fokus
Für den Client vereinfacht sich alles. Denn er muss nicht nach Anforderungen suchen, da er lediglich die von ihm angeforderten Attribute angezeigt bekommt. Das Konzept ist zum Beispiel praktisch und nachvollziehbar, wenn eine Bank lediglich die Telefonnummer und die ID eines bestimmten Kunden erfragt.
Die Query verhindert das Overfetching und damit die Übertragung unnötiger Attribute, die eher verwirren als Klarheit stiften würden. Natürlich können die Suchdaten ergänzt oder verändert werden. Allerdings wird jede Meldung mit einem JSON-Objekt namens „data“ nur über die angeforderten Tribute herausgegeben.
Gute Lösungsansätze – trotzdem neue Herausforderungen
In den Lösungsansätzen für bekannte REST Probleme hat GraphQL durchaus überzeugt. Doch mit jeder neuen Lösung ergeben sich auch neue Herausforderungen. Operationen wir Querys, Types und Mutators oder Revolvers erfordern eine tiefgreifende Einarbeitung in die GraphQL Entwicklung und Anwendung. Einige Vorgänge erschweren sich sogar, da die Komplexität enorm ist und zum Beispiel im Cache und bei Datei-Uploads auftritt. Hier erscheint REST API vielen Entwicklern einfacher, so dass es nach wie vor im Gebrauch und oftmals sogar die erste Wahl ist.
Caching-Komplexität: Wie und Warum?
Durch das HTTP-Caching erhalten der Client und der Server maximale Flexibilität. Alle bereits bekannten Ergebnisse werden temporär vorgehalten, wodurch sich die Abrufzeiten verkürzen. Durch die Nutzung nur eines Endpunktes profitiert GraphQLnicht von HTTP-Cachings. Der eigentliche Vorteil des Single Endpoints wird an diesem Punkt zu einem Nachteil, da der Server keinerlei Informationen zu vorab angeforderten Daten vorhält. Die Implementierung des Caching in GraphQL ist sehr schwierig und wird daher eher selten praktiziert. DataLoader ist eines der wenigen Tools, mit denen sich die Komplexität vereinfachen lässt. bei REST ist der ganze Prozess bedeutend einfacher.
Kein direkter Upload mit GraphQL möglich
Wenn Sie mit GraphQL eine Datei uploaden wollen, müssen Sie im Gegensatz zu REST APIs Umwege gehen. Das heißt konkret, dass Sie die Datei in Base64 konvertieren und anschließend eine Dekodierung eingeben müssen. Wenn Sie GraphQL als Wrapper verwenden, kann die Datei im Falle einer Mutation-Anfrage auch per REST API hochgeladen werden. Alle weiteren bekannten Lösungen sind noch komplizierter und somit nicht erwähnenswert.
Warum Anfragen eine hohe Last erzeugen …
Dieser Tatsache liegt die Graphentheorie zugrunde. Sie wird als Baum aufgezeigt, ebenso wie die Query ebenfalls in Form eines Baumes darstellbar ist. Allerdings gewinnt der Client an Freiheit, da die Tiefe des Baumes bei GraphQL nicht beschränkt wird. Das heißt auch, dass enorme Datenmengen in einen Zweig geladen werden und die Erreichbarkeit des Blattes schwierig gestalten können. Im Konkreten bedeutet das, dass sich die Anfrage verlängert und durchaus zu einem Ausfall des Servers führen kann. Dem gegenüber bietet REST mit mehreren Endpunkten einige Vorteile, vor allem, wenn es um komplizierte Anfragen geht.
Die Herausforderungen bei GraphQL sollten nicht unterschätzt werden. Allerdings arbeitet Facebook kontinuierlich daran, neue Lösungsansätze zu finden. Das geht allerdings und zu Ungunsten der Methodik mit einer gesteigerten Komplexität bei der Implementierung einher. Nur mit viel Aufwand und schier grenzenlosem Know-how erweist sich GraphQL aktuell als brauchbare Lösung.
Warum GraphQL REST keinesfalls ablöst
GraphQL ist mit dem 2. Level der REST APIs des Richardson Matury Models von Leonard Richardson vergleichbar. Von einer vollständigen REST API kann aus vielerlei Gründen noch keine Rede sein. Bis zu Grad 3 auf der Skala wird noch viel Zeit vergehen, da viele Entwickler nach wie vor auf REST vertrauen und den einfacheren Weg wählen. REST sollte keinesfalls abgewertet und als altmodisch dargestellt werden, auch wenn es bei diesen APIs einige Probleme gibt.
Fakt ist: Jede Medikation kommt mit Nebenwirkungen und unerwünschten Begleiterscheinungen. Genauso sollten Sie die Technologie betrachten, die verschiedene Herausforderungen mit sich bringt und nicht vom Zeitpunkt der Veröffentlichung an für jeden Nutzer einwandfrei funktioniert. Durch die hohe Flexibilität ist GraphQL durchaus eine Technologie der Zukunft, die mit den wachsenden Datenmengen zurecht kommt. Wenn es hingegen um kleine Datenmengen geht, können Sie auf die komplexe Performance von GraphQL verzichten und sich auf das Bewährte – die REST APIs berufen. Um Serverausfälle und den Verlust der Übersicht zu vermeiden, sollten Sie GraphQL nur dann anwenden, wenn Sie die Systematik verstehen und ausreichend Kapazitäten auf dem Server bereithalten.
Die Symbiose beider Varianten als Lösungsansatz
Ein Großteil der innovativen Applikationen unter der Entwicklung mit REST kann in einer Kombination aus REST APIs und GraphQL verarbeitet sein. Bei kleineren Datenmengen ist die Übersetzung nach GraphQL generell nicht nötig und wenig vorteilhaft. Wenn Sie Daten aus verschiedenen Ressourcen abrufen, können Sie sich diese Option von GraphQL zu Nutze machen. Auch ein Einsatz als Gateway ist möglich, wie wir in umfangreichen Praxistests ermittelt haben. In diesem Fall müssen Sie keine Übersetzung von REST in GraphQL vornehmen.
Herzlichst
Ihre Algopioniere
erstellt von Julia Rosen in Zusammenarbeit mit unserem Team
Weitere Informationen über die 123 Invest Gruppe erhalten Sie unter www.1-2-3-invest.de
