Wir schreiben das Jahr 2020. Ihr Team tendiert zunehmend dazu, einseitige Anwendungen zu erstellen oder zumindest reichhaltige Komponenten in reguläre mehrseitige Anwendungen einzubinden. [GraphQL](https://graphql.org/) ist jetzt [über zwei Jahre alt](https://en.wikipedia.org/wiki/GraphQL), was durch JavaScript Ökosystemstandards als ausgereift angesehen werden können. Wir waren ein wenig abenteuerlustig, also verzichteten wir auf die üblichen JSON-APIs und tauchten direkt ein - hier ist, was wir gelernt haben.

Sie benötigen einen GraphQL-Server

In den meisten Rahmenwerken, die für Web-Entwicklungsind die Werkzeuge zur Erstellung einer JSON-API bereits vorhanden. Sie können eine Routenstruktur aufbauen und einfach einige GETs und POSTs akzeptieren und dann eine JSON-Antwort ausgeben. Ruby on Rails hat sogar eine spezielle Projekt Einrichtungsschalter, der auf die üblichen HTML-Rendering-Goodies verzichtet und stattdessen eine solide Basis für APIs schafft. Daraus folgt, dass ein erfahrener Entwickler mit modernen Tools ein Backend in buchstäblich wenigen Minuten auf die Beine stellen kann.

Nicht so bei GraphQL. Es gibt zwar Server-Bibliotheken für viele SprachenWenn man eine solche Bibliothek einsetzt, hat man von Anfang an einen Geschwindigkeitsnachteil - einfach dadurch, dass man herausfinden muss, was für sein Ökosystem das Richtige ist. Persönlich mag ich auch nicht, dass der Begriff "Server" verwendet wird, um eine Bibliothek zu beschreiben, die in ein Projekt eingeführt werden kann.

Es gibt nur einen Endpunkt

Im Laufe der Jahre haben wir uns eine bestimmte Denkweise über die API-Struktur angewöhnt. Auf der grundlegendsten Ebene folgten wir einfach den REST-Praktiken. Das bedeutete, dass wir mehrere Endpunkte pro logischem Modell in unserer Anwendung erstellten. Diese Struktur ist sowohl für die API-Autoren als auch für die Benutzer leicht zu verstehen. Außerdem führt sie zu gut skalierten Methoden im Backend, wodurch die Argumentation über die Code so einfach wie über die API selbst. Diese Struktur lässt sich auch leicht mit einem Namensraum versehen, z. B. für die Zwecke von API-Versionierung.

GraphQL verwendet nur einen einzigen Endpunkt, in der Regel /graphql. Jede Anfrage an Ihre API kommt als POST-Anfrage an diesem Endpunkt an, und von dort aus ist es die Aufgabe des GraphQL-Servers, herauszufinden, was der Client will und entsprechend zu antworten.

Auf den ersten Blick wirkt es unhandlich: Stellen Sie sich vor, dass Sie alles in einer JSON-API mit einem einzigen Endpunkt machen wollen! Es macht jedoch bald Sinn, wenn Ihre API reift und einige Dinge durch andere ersetzt werden. Die Verwerfung in klassischen APIs erfolgt in der Regel auf der Ebene des Namespaces, indem man von v1 zu v2. GraphQL bietet viel mehr Kontrolle, bis hin zur Veraltung eines einzelnen Feldes. Stellen Sie sich vor, Sie könnten einem REST-API-Konsumenten sagen, dass Sie nicht wollen, dass er das Name zu verwenden und ausgefallener_name stattdessen! Es stellt sich heraus, dass das, was sich anfangs unhandlich anfühlte, in Wirklichkeit eine der besten Funktionen ist.

Alles wird getippt

Bei JSON gibt es nicht wirklich viele Möglichkeiten der Typisierung. Es gibt Zeichenketten, Zahlen, Arrays und Objekte. Darüber hinaus hat man kein Glück. Im Gegensatz dazu beginnt und endet in GraphQL alles mit Typen, denn selbst die Wurzel Abfrage und Mutation sind genau das - Typen. Die GraphQL-DSL erzwingt sowohl auf dem Server als auch auf dem Client eine Typprüfung und verhindert so alle Arten von bösen Überraschungen.

Dies ist sehr wichtig, zumal SPAs zunehmend selbst typgeprüft werden, sei es durch Verwendung von TypeScript oder Alternativen wie Flow. GraphQL macht es einfach, komplexe und zusammengesetzte Typen zusätzlich zu den Standardwerten einzuführen, und es wird schnell zur zweiten Natur für Entwickler sowohl im Backend als auch im Frontend.

Lesen Sie mehr: Testen von JavaScript...mit Ruby?!

Die Dokumente sind eingebaut

Bei einer klassischen JSON-API kann die Dokumentation ein nachträglicher Gedanke sein. Und selbst wenn dies nicht der Fall ist, gibt es eine Vielzahl von Methoden, aus denen man wählen kann. Verwenden wir ein Schema wie OpenAPI? Konvertieren wir sie dann mit Tools wie Swagger in eine für Menschen lesbare Form? Oder legen wir einfach einen ganzen Haufen Markdown-Dateien irgendwo ab? Auch wenn dieses Problem bereits mehrfach gelöst wurde, erfordert es immer noch bewusste Überlegungen und Anstrengungen des Teams - zuerst um die Dokumente zu erstellen, dann um sie zu aktualisieren und zu verbreiten. Es ist ein noch komplexeres Problem, wenn die API mehrere Abschnitte hat, die z. B. nur für bestimmte Benutzerrollen zugänglich sind.

In GraphQL ist die Dokumentation ein Bürger erster Klasse, da die meisten Server die Dokumentation Ihrer Typen und Anfragen an Ort und Stelle ermöglichen. Seit Anfang 2018 ist die GraphQL Schema Definition Language Teil der offiziellen Spezifikation, so dass es genau einen Weg gibt, eine GraphQL API zu dokumentieren. Da GraphQL außerdem die Möglichkeit bietet, die Sichtbarkeit bestimmter Teile des Graphen zu definieren, wird automatisch verhindert, dass Nutzer, die nicht darauf zugreifen sollen, Dokumente für das sehen, was sie nicht sehen können. Diese Entscheidung und die klaren Richtlinien waren ein großer Segen für das Team.

Es gibt nur zwei Arten von Maßnahmen

Im Gegensatz zu den HTTP-Aktionen GET, POST, PUT, PATCH und DELETE gibt es in GraphQL nur zwei Arten von Aktionen: Abfragen und Mutationen. Der Hauptunterschied besteht darin, dass Mutationen den Zustand des Systems verändern können und werden, während Abfragen nur passiv Daten auslesen.

Ich muss zugeben, dass ich in dieser Frage noch unschlüssig bin. Ich genieße die Fülle von HTTP-Verben für die Interaktion mit Ressourcen und die Möglichkeit, genau das richtige Werkzeug für die jeweilige Aufgabe zu verwenden. GraphQL macht es einfacher, sich um die haarigen Fälle zu kümmern, in denen irgendeines der HTTP-Verben nicht genau passt, bringt aber den Nachteil mit sich, dass man sich Gedanken darüber machen muss, was eine bestimmte Mutation tatsächlich bewirken wird. Man kann auch darauf hinweisen, dass man, da es keine eingebaute Standard-Namenskonvention gibt, interne Styleguides erstellen muss oder riskiert, ein inkonsistentes Durcheinander zu bauen.

Sie brauchen einen Kunden

Die Interaktion mit REST-APIs über HTTP ist in der Vanilleversion von JavaScript sehr einfach, noch einfacher wird es mit der modernen abrufen. API. Im Gegensatz dazu sollten Sie für GraphQL eine Client-Bibliothek verwenden, wenn Sie eine wirklich anständige Leistung wünschen. Es ist nicht unmöglich, mit einer GraphQL-API zu interagieren, wenn man nur Vanilla JavaScript verwendet - schließlich handelt es sich nur um POST-Anfragen. Die Verwendung von altbewährten Webtechnologien wie Request Caching für gängige API-Aufrufe wird jedoch nicht funktionieren, da POST-Anfragen im Allgemeinen nicht zwischengespeichert werden.

Jeder vernünftige GraphQL-Client implementiert einen clientseitigen Ergebnis-Caching-Mechanismus und viele weitere Funktionen. Dank all dieser Möglichkeiten ist die Konfiguration eines GraphQL-Clients auf der Einstiegsebene eine völlig verblüffende Aufgabe. Für den Einstieg in GraphQL empfehle ich insbesondere einen Blick auf Apollo-Boost da sie mit sehr vernünftigen Standardeinstellungen geliefert wird.

Der Kunde wählt die Daten aus

Wir kennen das alle: Wir ziehen eine Liste von Daten aus der API und es fehlt ein wichtiges Feld über ein verwandtes Modell. Wir implementieren dann einen Hack, der N+1 Anfragen umfasst, und schimpfen auf die Backend-Entwickler, die sich beeilen, um die Daten schnell hinzuzufügen. Bei einer gut implementierten GraphQL-API ist das in der Regel nicht der Fall, da wir einfach so tief in die Daten eindringen können, wie wir wollen. Sie möchten die Adresse eines Kunden zu einer Bestellung in diesem Stapel sehen? Kein Problem - zumindest theoretisch, und das führt uns zu einem schönen Beispiel...

Komplexität ist schwieriger vorherzusehen

Wenn man GraphQL von der Backend-Seite aus entwirft, kann es schwierig sein, an all die Tiefe zu denken, die ein Client in den Graphen eintauchen kann. Es gibt viele Möglichkeiten, die Nutzung Ihres Graphen zu instrumentieren und zu beobachten, und wenn Sie Ihre Front-End-Kollegen eine Weile damit spielen lassen, können Sie feststellen, dass einige langwierige Abfragen ziemlich fantasievolle Lesevorgänge in Ihrem Datenspeicher durchführen. In einer REST-API ist dies leichter zu kontrollieren, da Sie den Umfang der Daten, auf die in einer einzigen Anfrage zugegriffen wird, leicht bestimmen können. Oftmals kann sich diese verpasste Komplexität bei der Freigabe für die Produktion bitter rächen. Oftmals ist auch nicht klar, wie man aus diesem Loch, das man sich selbst gegraben hat, wieder herauskommt.

Nummerierte Seiten sind wirklich schwer

Dies ist ein Kritikpunkt, der eigentlich nur ein Augenzwinkern ist. Man spürt deutlich, dass GraphQL bei und für Facebook entwickelt wurde, wenn man sich ansieht, wie der vorgesehene Paginierungsmechanismus funktioniert. Die so genannten Connections sind im Grunde genommen endlose Ströme von Graphkanten, durch die man mit Hilfe von Cursorn anstelle der klassischen Seiten navigiert. Es ist zwar leicht einzusehen, wie das zu einem endlosen Feed von Beiträgen im Stil von Facebook passt, aber wenn man eine übersichtlich paginierte Liste mit der Möglichkeit haben möchte, z. B. zu Seite 42 zu gehen, wird man es viel schwerer haben. Es gibt natürlich Möglichkeiten, das zu umgehen, aber das sind sie ja auch - Umgehungen.

Würden wir es wieder tun?

Bei all den oben aufgeführten Kritikpunkten und Unterschieden denken Sie wahrscheinlich, dass wir GraphQL als ein misslungenes Experiment betrachten und direkt zu REST-APIs zurückkehren. Das ist nicht der Fall. Wenn überhaupt, dann arbeiten wir daran, GraphQL in Projekten im gesamten Unternehmen verstärkt einzusetzen. Es ist eine großartige Technologie, die unsere Arbeit einfacher und besser gemacht hat. Allerdings haben wir anfangs in GraphQL investiert, ohne uns völlig im Klaren darüber zu sein, was für Wachstumsschmerzen wir durchmachen werden.

Wenn Sie glauben, dass GraphQL das Richtige für Sie sein könnte, ermutige ich Sie, den Schritt zu wagen. Geben Sie sich ausreichend Zeit und Raum, um sicher zu scheitern, und Sie werden die Vorteile schon bald ernten!

Lesen Sie auch:

– Wie verwaltet man effektiv Remote-Entwickler? Der Leitfaden für CTOs

– Python vs. Ruby? Welche Technologie sollten Sie für die Produktentwicklung verwenden?

– Eine Kurzanleitung für den Aufbau und die Entwicklung Ihres eigenen Marktplatzes. Was ist wichtig zu wissen?