Graph QL news

Seit den Anfängen des Internets war es für Entwickler nie leicht, eine API zu erschaffen. Der Weg zu einer funktionierenden Schnittstelle muss dabei immer mit der Zeit gehen. Nur so kann immer eine durchdachte, intuitive und gut funktionierende API bauen.

Dabei hat in den letzten Jahren besonders eine API immer mehr Zuspruch unter Entwicklern gefunden: GraphQL. Viele Unternehmen begannen auf Basis dieser Technologie ihre Schnittstellen zu entwickeln. Doch was ist GraphQL eigentlich? Es ist eine sogenannte Query Language, eine Sprache zur Abfrage von Daten. Sie wurde 2012 von Facebook ins Leben gerufen, und ist seit 2015 öffentlich verfügbar. Und ab da begann ihre Verbreitung rasant: Unternehmen wie Spotify, GitHub und Netflix setzen auf GraphQL.

Seit Version 3.2 ist GraphQL fester Bestandteil unseres primär eingesetzten Content Management Systems Craft CMS. Wir dachten daher, es ist an der Zeit für einen detaillierten Einblick. In diesem und weiteren Artikeln werden wir nunmehr erläutern, was genau diese Query Language ist, und wie man mit ihr schnell und einfach potente Schnittstellen bereitstellen kann.

Doch lasst uns zuerst anfangen, die Probleme der bis dato als Standard definierten REST-API aufzuzeigen. Und wie GraphQL diese vermeidet. Auch werden wir erläutern, warum so viele Unternehmen ihre Schnittstellen mit GraphQL umsetzen und warum deshalb dieser die Zukunft gehört.

Time to rest, REST

Vor vielen Jahren haben wir unser Schnittstellen-Design von soap auf Rest umgestellt. Und das hat auch gut funktioniert, zumindest eine Zeit lang. Wir haben dadurch in unserer Konzeption und Umsetzung mehr Flexibilität. Doch Webseiten und Web-Applikationen wurden immer anspruchsvoller, die Anforderungen an deren APIs dadurch auch. Sie entwickelten sich die APIs evolutionär bedingt weiter. Doch dadurch stieß man mit REST immer häufiger auf Probleme. Diese wären:

Zu viele Endpunkte

Jede Ressource wird und REST durch einen Endpunkt dargestellt. Unter produktiven Umgebungen hat so jede Applikation zum Schluss für jede Ressource einen Endpunkt. Will man nun eine Ressource via GET Request abfragen, benötigt man speziell für diese eine Abfrage mit spezifischen Parametern einen Endpunkt. Das Gleiche ist auch der Fall, wenn man einen POST Request machen will: auch hier wird speziell dafür ein Endpunkt benötigt. Doch was genau daran ist problematisch? Ganz einfach: wollen wir beispielsweise eine Social Internet Plattform oder eine interaktive Website mit User Interaktionen erstellen, bräuchten wir unzählige Endpunkte. Und die dadurch entstandene Schnittstelle müsste an unzähligen Stellen regelmäßig gewartet und gegebenenfalls erweitert werden.

Zu viel oder zu wenig Informationen in der Schnittstellen-Ausgabe

Auch nervte uns bei der Datenabfrage via REST ein Aspekt relativ häufig: das sogenannte Over-Fetching oder Under-Fetching von Daten. So werden entweder Zuviel oder zu wenig Daten per Abfrage mitgeteilt. Das liegt daran, dass REST immer eine feste Struktur zurücklieferte. Da konnte man nur umgehen, indem man -richtig geraten- einen spezifischen Endpunkt erstellte.

Bedeutet: Auch wenn wir zum Beispiel aus einer Gin-Datenbank lediglich die Daten Destille, das Destillations-Datum und die Charge abfragen wollen, gibt und REST immer das gesamte Objekt als Antwort zurück. Das wäre Over-Fetching.

Ein gutes Beispiel für Under-Fetching ist zum Beispiel, wenn wir Daten aus zwei Ressourcen benötigen: wollen wir also nicht nur aus der Ressource „Gin“ den Namen und die geschmackliche Ausrichtung, sondern auch aus der Ressource „Tonic“ den Namen und die Geschmacksnote beziehen, mussten wir zwei Endpunkte mit zwei Abfragen erzeugen. Bei kleinen Projekten wäre das Koch vertretbar, aber bei großen oder skalierenden Websites wäre das untragbar. Und je mehr Daten wir abfragen oder kombinieren wollen, umso mehr Endpunkte müssen wir erstellen und umso mehr Workload erzeugen deren Abfragen.

Version...what?

Auch nervten verschiedene Versionen der REST-Schnittstellen extrem. So sind wir häufiger über APIs mit V1 oder V2 gestolpert. Mit GraphQL Besuch man keine Versionierung, man kann sie einfach weiterentwickeln indem man neue Typen hinzufügt oder alte löscht. Und diese Weiterentwicklung lässt sich einfach über das Schreiben von neuen Code bewerkstelligen: Einfach neue Typen, Abfragen oder Mutationen schreiben. Ohne eine neue Version erstellen zu müssen.

Darum ist GraphQL die Zukunft der APIs

Damals, in 2012 stand Facebook also vor einem Problem, welches schlussendlich zur Geburt von GraphQL führen sollte: als das soziale Netzwerk in der Entwicklung seiner mobilen Applikationen war, standen sie bei REST vor den bereits erläuterten Problemen:

  1. schlechte Performance
  2. Viel zu viele Endpunkte
  3. Over-Fetching oder Under-Fetching von Daten
  4. Die Veröffentlichung von immer neuen Schnittstellen-Versionen, sobald sich irgendetwas änderte in den Abfragen
  5. Schwer zu pflegende und zu dokumentierende API

Dadurch haben viele Facebook-Entwickler eine neuen Weg entwickelt, um diese Abfragen einfacher und flexibler zu gestalten, und nannten es schließlich: GraphQL! Es ist wie REST, nur flexibel und auf Steroiden;)

Ein API-Endpunkt, alle Möglichkeiten

Es gibt keinen Grund, unendliche viele Endpunkte zu definieren. In GraphQL gibt es einen einzigen Endpunkt. Und mit diesem können wir alle Daten, die wir benötigen,mit einem einzigen Request abfragen. Von Prinzip her bündelt GraphQL alle Anfragen, Typen, Mutationen und Objekte zu einem einzigen Endpunkt, und macht diesen verfügbar. Und mit diesem Endpunkt können wir alles anstellen, was wir für eine performante API benötigen. Das reduziert den Entwicklungsaufwand einer API extrem. Und die Wartung geht sich weitaus einfacher von Statten. Auch fällt durch den Ansatz mit diesem einen Endpunkt eine umfassende Dokumentation weg. Im Prinzip erklärt sich der Query-Code von selbst, da er sowohl logisch, als auch übersichtlich und dadurch jederzeit nachvollziehbar ist. Das macht es Fremdentwicklern einfach, sich auf diese Basis aufzuschalten und eigene Entwicklungen voranzutreiben.

Nur das, was wirklich gebraucht wird

Durch die Verwendung von GraphQL gehört Over-Fetching und Under-Fetching der Vergangenheit an. Es werden nur die Daten geholt, welche sich wirklich in der API gebraucht werden. Auch die dadurch von vornherein vermiedenen unzähligen Abfragen sorgen für eine extrem schnelle und ressourcenschonende Performance. Vor allem bei langsamen Netzwerk-Verbindungen.

GraphQL macht es extrem einfach, in Craft CMS APIs zu schreiben.

Viele Entwickler sind nach wie vor den Irrglauben erlegen, dass die Entwicklung von GraphQL APIs kompliziert sei. Und nur auf JavaScript Basis funktioniert. Doch dabei läuft diese API mittlerweile auf über 15 Programmiersprachen. Auch der Single-Enpoint-Ansatz ist nicht zu unterschätzen. Also haut in die Tasten und baut APIs damit!

Alles Weichen auf Zukunft gestellt

Das GraphQL unter einer Open Source Lizenz veröffentlicht wird, macht es der Entwickler-Community leicht, zu Verbesserungen und Erweiterungen beizutragen. Wie bei FUCHSBAU.media selbst sind Teil dieser Community. Ideen finden Gehör und Bugs werden zeitnah ausgemerzt. Seit Facebook diesen Schritt der Öffnung wagte, hat das gesamte GraphQL-Projekt an Fahrt aufgenommen und sich die Akzeptanz vielen Entwickler und namhafte Unternehmen gesichert. Und die Zahl der aktiven Abwendungen der API wächst ständig an.

Klar wird GraphQL die REST-API nie gänzlich von Markt verdrängen. Dazu gibt es noch viel zu viele Web-Projekte da draußen,die auf diese Schnittstelle angewiesen sind. Aber es ist ein moderner und durchdachter Weg zur Entwicklung leistungsstarker APIs.

Doch aus unserer Sicht und das viele Top-Companies international auf GraphQL schwören denken wir:

GraphQL ist die Zukunft der APIs

Und dass im November 2018 unter dem Dach der Linux Foundation die GraphQL Foundation ins Leben gerufen wurde, an der sich unzählige Unternehmen, darunter Airbnb, Apollo, Coursera, Elementl, Facebook, GitHub, Hasura, Prisma, Shopify, und Twitter beteiligen, zeigt wie ernst es um die Sache steht. Diese Foundation wird Hand und Hand mit der Open Source Gemeinde dafür sorgen, dass GraphQL langfristig mit Support, Tools und Dokumentation versorgt wird.

Craft CMS wird durch GraphQL noch vielseitiger

Unser Lieblings-Content-Management-System Craft CMS besitzt seit Version 3.2 eine native GraphQL-Schnittstelle direkt im Core des CMS. Dadurch haben sich die ohnehin schon mannigfaltigen Verwendungsmöglichkeiten um ein Vielfaches erweitert. Was wir nunmehr alles anstellen können damit, werden wir im weiteren Beträgen und Tutorials aufzeigen.