GraphQL lernen

Kapitel 1. Willkommen bei GraphQL

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Bevor ihn die englische Königin zum Ritter schlug, war Tim Berners-Lee ein Programmierer. Er arbeitete am CERN, dem europäischen Labor für Teilchenphysik in der Schweiz, und war von vielen talentierten Forscherinnen und Forschern umgeben.Berners-Lee wollte seinen Kolleginnen und Kollegen helfen, ihre Ideen auszutauschen, und beschloss daher, ein Netzwerk zu schaffen, in dem Wissenschaftlerinnen und Wissenschaftler Informationen veröffentlichen und aktualisieren konnten. Das Projekt wurde schließlich zum ersten Webserver und zum ersten Webclient, und der "WorldWideWeb"-Browser (später in "Nexus" umbenannt) wurde im Dezember 1990 am CERN eingeführt.

Mit seinem Projekt machte Berners-Lee es möglich, dass Forscherinnen und Forscher Webinhalte auf ihren eigenen Computern ansehen und aktualisieren konnten. Das "WorldWideWeb" bestand aus HTML, URLs, einem Browser und einer WYSIWYG-Oberfläche, mit der Inhalte aktualisiert werden konnten.

Das Internet besteht heute nicht mehr nur aus HTML in einem Browser. Das Internet sind Laptops. Es sind Armbanduhren. Es ist ein Smartphone. Es ist ein RFID-Chip (Radio Frequency Identification) in deinem Skiliftticket. Es ist ein Roboter, der deine Katze mit Leckerlis füttert, wenn du nicht in der Stadt bist.

Die Kunden sind heute zahlreicher, aber wir streben immer noch danach, dasselbe zu tun: Daten so schnell wie möglich irgendwo zu laden. Unsere Anwendungen müssen leistungsfähig sein, denn unsere Nutzer/innen stellen hohe Anforderungen an uns. Sie erwarten, dass unsere Anwendungen unter allen Bedingungen gut funktionieren: von 2G auf Mobiltelefonen bis hin zu blitzschnellem Glasfaser-Internet auf Desktop-Computern mit großen Bildschirmen. Schnelle Apps machen es für mehr Menschen einfacher, mit unseren Inhalten zu interagieren. Schnelle Apps machen unsere Nutzer/innen glücklich. Und ja, schnelle Apps bringen uns Geld ein.

Daten schnell und vorhersehbar vom Server zum Client zu bringen, ist die Geschichte des Webs, Vergangenheit, Gegenwart und Zukunft. Auch wenn in diesem Buch oft auf die Vergangenheit Bezug genommen wird, geht es hier um moderne Lösungen. Wir sind hier, um über die Zukunft zu sprechen. Wir sind hier, um über GraphQL zu sprechen.

Was ist GraphQL?

GraphQL ist eine Abfragesprache für deine APIs. Es ist auch eine Laufzeitumgebung für die Ausführung von Abfragen mit deinen Daten. Der GraphQL-Dienst ist transportunabhängig, wird aber normalerweise über HTTP bereitgestellt.

Um eine GraphQL-Abfrage und ihre Antwort zu demonstrieren, schauen wir unsSWAPI an, die Star Wars API. SWAPI ist eine Representational State Transfer (REST)-API, die mit GraphQL ummantelt wurde. Mit ihr können wir Abfragen senden und Daten empfangen.

Eine GraphQL-Abfrage fragt nur nach den Daten, die sie benötigt. Abbildung 1-1 ist ein Beispiel für eine GraphQL-Abfrage. Die Abfrage steht auf der linken Seite. Wir fragen die Daten für eine Person, Prinzessin Leia, ab. Wir erhalten den Datensatz von Leia Organa, weil wir angeben, dass wir die fünfte Person wollen (personID:5). Als nächstes fragen wir nach drei Datenfeldern: name, birthYear, und created. Auf der rechten Seite ist unsere Antwort: JSON-Daten, die so formatiert sind, dass sie der Form unserer Abfrage entsprechen. Diese Antwort enthält nur die Daten, die wir brauchen.

Abbildung 1-1. Personenabfrage für die Star Wars API

Dann können wir die Abfrage anpassen, denn Abfragen sind interaktiv. Wir können sie ändern und sehen ein neues Ergebnis. Wenn wir das Feld filmConnection hinzufügen, können wir den Titel von jedem von Leias Filmen abfragen, wie Abbildung 1-2 zeigt.

Abbildung 1-2. Verbindungsabfrage

Die Abfrage ist verschachtelt und kann, wenn sie ausgeführt wird, verwandte Objekte durchlaufen. So können wir mit einer HTTP-Anfrage zwei Arten von Daten abfragen. Wir müssen nicht mehrere Roundtrips machen, um mehrere Objekte aufzuschlüsseln. Wir erhalten keine zusätzlichen, unerwünschten Daten über diese Typen. Mit GraphQL können unsere Kunden alle Daten, die sie benötigen, mit einer einzigen Anfrage abrufen.

Immer wenn eine Abfrage auf einem GraphQL-Server ausgeführt wird, wird sie gegen ein Typsystem validiert. Jeder GraphQL-Dienst definiert Typen in einem GraphQL-Schema. Du kannst dir ein Typsystem als einen Entwurf für die Daten deiner API vorstellen, der durch eine Liste von Objekten unterstützt wird, die du definierst. Die Personenabfrage von vorhin wird zum Beispiel durch ein Person Objekt unterstützt:

type Person {
    id: ID!
    name: String
    birthYear: String
    eyeColor: String
    gender: String
    hairColor: String
    height: Int
    mass: Float
    skinColor: String
    homeworld: Planet
    species: Species
    filmConnection: PersonFilmsConnection
    starshipConnection: PersonStarshipConnection
    vehicleConnection: PersonVehiclesConnection
    created: String
    edited: String
}

Der Typ Person definiert alle Felder und ihre Typen, die für die Abfrage von Princess Leia zur Verfügung stehen. In Kapitel 3 gehen wir näher auf das Schema und das Typensystem von GraphQL ein.

GraphQL wird oft als deklarative Datenabfragesprache bezeichnet. Damit meinen wir, dass Entwickler/innen ihre Datenanforderungen auflisten, ohne sich Gedanken darüber zu machen , wie sie die Daten bekommen. GraphQL-Serverbibliotheken gibt es in einer Vielzahl von Sprachen, darunter C#, Clojure, Elixir, Erlang, Go, Groovy, Java, JavaScript, .NET, PHP, Python, Scala und Ruby.¹

In diesem Buch konzentrieren wir uns darauf, wie man GraphQL-Dienste mit JavaScript erstellt. Alle Techniken, die wir in diesem Buch besprechen, sind für GraphQL in jeder Sprache anwendbar.

Die GraphQL-Spezifikation

GraphQL ist eine Spezifikation (Spec) für die Client-Server-Kommunikation. Was ist eine Spezifikation? Eine Spezifikation beschreibt die Fähigkeiten und Eigenschaften einer Sprache. Wir profitieren von Sprachspezifikationen, weil sie ein gemeinsames Vokabular und bewährte Methoden für die Nutzung der Sprache durch die Gemeinschaft bereitstellen.

Ein ziemlich bemerkenswertes Beispiel für eine Software-Spezifikation ist die ECMAScript-Spezifikation. Von Zeit zu Zeit kommt eine Gruppe von Vertretern von Browserfirmen, Technologieunternehmen und der Community zusammen und legt fest, was in die ECMAScript-Spezifikation aufgenommen (und was weggelassen) werden soll. Das Gleiche gilt für GraphQL. Eine Gruppe von Personen hat sich zusammengesetzt und geschrieben, was in die Sprache aufgenommen (und was weggelassen) werden soll. Dies dient als Leitfaden für alle Implementierungen von GraphQL.

Als die Spezifikation veröffentlicht wurde, haben die Macher von GraphQL auch eine Referenzimplementierung eines GraphQL-Servers in JavaScript zur Verfügung gestellt - graphql.js. Diese Referenzimplementierung ist eine nützliche Blaupause, aber das Ziel dieser Referenzimplementierung ist nicht, dir vorzuschreiben, welche Sprache du für die Implementierung deines Dienstes verwenden sollst. Sie ist lediglich ein Leitfaden. Nachdem du die Abfragesprache und das Typensystem verstanden hast, kannst du deinen Server in jeder beliebigen Sprache erstellen.

Wenn eine Spezifikation und eine Implementierung unterschiedlich sind, was steht dann eigentlich in der Spezifikation? Die Spezifikation beschreibt die Sprache und Grammatik, die du beim Schreiben von Abfragen verwenden solltest. Sie legt auch ein Typensystem sowie die Ausführungs- und Validierungsmechanismen dieses Typensystems fest. Darüber hinaus ist die Spezifikation nicht besonders rechthaberisch. GraphQL schreibt nicht vor, welche Sprache zu verwenden ist, wie die Daten gespeichert werden sollen oder welche Clients unterstützt werden sollen. Für die Abfragesprache gibt es Richtlinien, aber das eigentliche Design deines Projekts ist dir überlassen. (Wenn du dich mit der ganzen Sache befassen möchtest, kannst du die Dokumentation lesen).

Gestaltungsprinzipien von GraphQL

Auch wenn GraphQL keine Kontrolle darüber hat, wie du deine API aufbaust, bietet es doch einige Richtlinien, wie du über einen Dienst nachdenken solltest:²

Hierarchisch

Eine GraphQL-Abfrage ist hierarchisch aufgebaut. Felder sind in anderen Feldern verschachtelt und die Abfrage ist so geformt wie die Daten, die sie zurückgibt.

Produktorientiert

GraphQL wird durch den Datenbedarf des Kunden und die Sprache und Laufzeit, die den Kunden unterstützen, bestimmt.

Starkes Tippen

Ein GraphQL-Server wird durch das GraphQL-Typensystem unterstützt. Im Schema hat jeder Datenpunkt einen bestimmten Typ, gegen den er validiert wird.

Kunden-spezifische Abfragen

Ein GraphQL-Server stellt die Fähigkeiten zur Verfügung, die die Clients nutzen dürfen.

Introspektive

Die GraphQL-Sprache ist in der Lage, das Typensystem des GraphQL-Servers abzufragen.

Nachdem wir nun wissen, was die GraphQL-Spezifikation ist, wollen wir uns ansehen, warum sie erstellt wurde.

Die Ursprünge von GraphQL

Im Jahr 2012 beschloss Facebook, die nativen mobilen Apps der Anwendung zu überarbeiten. Die iOS- und Android-Apps des Unternehmens waren nur dünne Hüllen um die Ansichten der mobilen Website. Facebook hatte einen RESTful Server und FQL (Facebooks Version von SQL) Datentabellen. Die Leistung war mangelhaft und die Apps stürzten oft ab. An diesem Punkt erkannten die Ingenieure, dass sie die Art und Weise, wie die Daten an ihre Client-Anwendungen gesendet wurden, verbessern mussten.³

Das Team aus Lee Byron, Nick Schrock und Dan Schafer beschloss, seine Daten von der Client-Seite aus zu überdenken. Sie machten sich daran, GraphQL zu entwickeln, eine Abfragesprache, die die Fähigkeiten und Anforderungen der Datenmodelle für die Client/Server-Anwendungen des Unternehmens beschreiben sollte.

Im Juli 2015 veröffentlichte das Team seine erste GraphQL-Spezifikation und eine Referenzimplementierung von GraphQL in JavaScript namens graphql.js. Im September 2016 verließ GraphQL das Stadium der "technischen Vorschau". Das bedeutete, dass GraphQL offiziell produktionsreif war, obwohl es bei Facebook bereits seit Jahren in der Produktion eingesetzt wurde. Heute steuert GraphQL fast die gesamte Datenabfrage von Facebook und wird von IBM, Intuit, Airbnb und vielen anderen in der Produktion eingesetzt.

Geschichte des Datentransports

GraphQL stellt einige sehr neue Ideen vor, die aber alle im historischen Kontext des Datentransports verstanden werden sollten. Wenn wir über Datentransport nachdenken, versuchen wir herauszufinden, wie wir Daten zwischen Computern hin- und herschicken können. Wir fordern Daten von einem entfernten System an und erwarten eine Antwort.

Remote Procedure Call

In den 1960er Jahren wurde der Remote Procedure Call (RPC) erfunden. Ein RPC wurde vom Client initiiert, der eine Anforderungsnachricht an einen entfernten Computer schickte, um etwas zu tun. Der entfernte Computer schickte eine Antwort an den Client. Diese Computer unterschieden sich zwar von den Clients und Servern, die wir heute verwenden, aber der Informationsfluss war im Grunde derselbe: Der Client forderte Daten an und erhielt eine Antwort vom Server.

Simple Object Access Protocol

In den späten 1990er Jahren entstand bei Microsoft das Simple Object Access Protocol (SOAP). SOAP verwendete XML zur Kodierung einer Nachricht und HTTP als Transportmittel. SOAP nutzte auch ein Typensystem und führte das Konzept der ressourcenorientierten Datenaufrufe ein. SOAP bot ziemlich vorhersehbare Ergebnisse, sorgte aber auch für Frustration, weil die SOAP-Implementierungen ziemlich kompliziert waren.

REST

Das API-Paradigma, mit dem du heute wahrscheinlich am meisten vertraut bist, ist REST. REST wurde im Jahr 2000 in der Dissertation von Roy Fielding ( ) an der University of California-Irvine definiert. Er beschrieb eine ressourcenorientierte Architektur, in der sich die Nutzer durch Webressourcen bewegen, indem sie Operationen wie GET, PUT, POST und DELETE durchführen. Das Ressourcennetzwerk kann man sich als virtuelle Zustandsmaschine vorstellen, und die Aktionen (GET, PUT, POST, DELETE) sind Zustandsänderungen innerhalb der Maschine. Wir halten das heute vielleicht für selbstverständlich, aber das war ziemlich gewaltig. (Oh, und Fielding hat seinen Doktortitel bekommen.)

In einer RESTful-Architektur stellen die Routen Informationen dar. Wenn du zum Beispiel Informationen von jeder dieser Routen anforderst, erhältst du eine bestimmte Antwort:

/api/food/hot-dog
/api/sport/skiing
/api/city/Lisbon

REST ermöglicht es uns, ein Datenmodell mit einer Vielzahl von Endpunkten zu erstellen - ein viel einfacherer Ansatz als frühere Architekturen. Es bot eine neue Möglichkeit, Daten im immer komplexer werdenden Web zu verarbeiten, ohne dass ein bestimmtes Antwortformat vorgeschrieben war. Ursprünglich wurde REST mit XML verwendet. AJAX war ursprünglich ein Akronym, das für Asynchronous JavaScript And XML stand, weil die Antwortdaten einer Ajax-Anfrage als XML formatiert wurden (heute ist es ein eigenständiges Wort, das "Ajax" geschrieben wird). Für Webentwicklerinnen und -entwickler bedeutete dies einen schmerzhaften Schritt: Sie mussten die XML-Antworten parsen, bevor die Daten in JavaScript verwendet werden konnten.

Bald darauf wurde die JavaScript Object Notation (JSON) von Douglas Crockford entwickelt und standardisiert. JSON ist sprachunabhängig und bietet ein elegantes Datenformat, das von vielen verschiedenen Sprachen analysiert und genutzt werden kann. Crockford schrieb daraufhin das bahnbrechende Buch JavaScript: The Good Parts (O'Reilly, 2008), in dem er uns wissen lässt, dass JSON zu den guten Seiten gehört.

Der Einfluss von REST ist unbestreitbar. Es wird für die Entwicklung unzähliger APIs verwendet, und Entwickler auf allen Ebenen haben davon profitiert. Es gibt sogar Anhänger, die so sehr daran interessiert sind, darüber zu streiten, was RESTful ist und was nicht, dass man sie als RESTafarians bezeichnet hat. Wenn das so ist, warum haben Byron, Schrock und Schafer sich dann auf den Weg gemacht, um etwas Neues zu schaffen? Die Antwort finden wir in einigen Mängeln von REST.

REST Nachteile

Als GraphQL zum ersten Mal veröffentlicht wurde, wurde es von einigen als Ersatz für REST angepriesen. "REST ist tot!", riefen frühe Anwender und ermutigten uns alle, eine Schaufel in den Kofferraum zu werfen und unsere ahnungslosen REST-APIs in den Wald zu jagen. Das war großartig, um Klicks in Blogs zu bekommen und Gespräche auf Konferenzen anzustoßen, aber GraphQL als REST-Killer darzustellen, ist eine grobe Vereinfachung. Eine differenziertere Sichtweise ist, dass REST im Laufe der Entwicklung des Internets unter bestimmten Bedingungen Anzeichen von Überlastung gezeigt hat. GraphQL wurde entwickelt, um diese Überlastung zu verringern.

Overfetching

Angenommen, wir bauen eine App, die Daten aus der REST-Version von SWAPI verwendet. Zuerst müssen wir einige Daten über die Figur Nummer 1, Luke Skywalker, laden.⁴ Wir können eine GET-Anfrage für diese Informationen stellen, indem wir https://swapi.co/api/people/1/ besuchen . Die Antwort sind diese JSON-Daten:

{
  "name": "Luke Skywalker",
  "height": "172",
  "mass": "77",
  "hair_color": "blond",
  "skin_color": "fair",
  "eye_color": "blue",
  "birth_year": "19BBY",
  "gender": "male",
  "homeworld": "https://swapi.co/api/planets/1/",
  "films": [
    "https://swapi.co/api/films/2/",
    "https://swapi.co/api/films/6/",
    "https://swapi.co/api/films/3/",
    "https://swapi.co/api/films/1/",
    "https://swapi.co/api/films/7/"
  ],
  "species": [
    "https://swapi.co/api/species/1/"
  ],
  "vehicles": [
    "https://swapi.co/api/vehicles/14/",
    "https://swapi.co/api/vehicles/30/"
  ],
  "starships": [
    "https://swapi.co/api/starships/12/",
    "https://swapi.co/api/starships/22/"
  ],
  "created": "2014-12-09T13:50:51.644000Z",
  "edited": "2014-12-20T21:17:56.891000Z",
  "url": "https://swapi.co/api/people/1/"
}

Das ist eine riesige Antwort. Die Antwort übersteigt den Datenbedarf unserer App. Wir brauchen nur die Informationen für Name, Masse und Größe:

  {
    "name": "Luke Skywalker",
    "height": "172",
    "mass": "77"
  }

Dies ist ein klarer Fall von Overfetching - wirbekommen eine Menge Daten zurück, die wir nicht brauchen. Der Client benötigt drei Datenpunkte, aber wir bekommen ein Objekt mit 16 Schlüsseln zurück und senden Informationen über das Netzwerk, die nutzlos sind.

Wie würde diese Anfrage in einer GraphQL-Anwendung aussehen? Hier in Abbildung 1-3 wollen wir immer noch den Namen, die Größe und die Masse von Luke Skywalker.

Abbildung 1-3. Luke Skywalker Abfrage

Auf der linken Seite stellen wir unsere GraphQL-Abfrage. Wir fragen nur nach den Feldern, die wir wollen. Auf der rechten Seite erhalten wir eine JSON-Antwort, die diesmal nur die angeforderten Daten enthält und nicht 13 zusätzliche Felder, die für die Übertragung von einem Mobilfunkmast zu einem Telefon benötigt werden, ohne jeden Grund. Wir fragen nach Daten in einer bestimmten Form und erhalten die Daten in dieser Form zurück. Nicht mehr und nicht weniger. Das ist deklarativer und führt wahrscheinlich zu einer schnelleren Antwort, da keine fremden Daten abgefragt werden.

Underfetching

Unser Projektmanager ist gerade bei uns aufgetaucht und möchte der Star Wars-App eine weitere Funktion hinzufügen. Zusätzlich zu Name, Größe und Masse müssen wir jetzt auch eine Liste der Filmtitel aller Filme anzeigen, in denen Luke Skywalker mitspielt. Nachdem wir die Daten von https://swapi.co/api/people/1/ angefordert haben , müssen wir noch weitere Daten abfragen. Das bedeutet, dass wir zu wenig abgefragt haben.

Um den Titel jedes Films zu erhalten, müssen wir die Daten von jeder der Routen im Array films abrufen:

  "films": [
    "https://swapi.co/api/films/2/",
    "https://swapi.co/api/films/6/",
    "https://swapi.co/api/films/3/",
    "https://swapi.co/api/films/1/",
    "https://swapi.co/api/films/7/"
  ]

Um diese Daten zu erhalten, brauchen wir eine Anfrage für Luke Skywalker (https://swapi.co/api/people/1/) und dann fünf weitere für jeden der Filme. Für jeden Film erhalten wir ein weiteres großes Objekt. Dieses Mal verwenden wir nur einen Wert.

  {
  "title": "The Empire Strikes Back",
  "episode_id": 5,
  "opening_crawl": "...",
  "director": "Irvin Kershner",
  "producer": "Gary Kurtz, Rick McCallum",
  "release_date": "1980-05-17",
  "characters": [
    "https://swapi.co/api/people/1/",
    "https://swapi.co/api/people/2/",
    "https://swapi.co/api/people/3/",
    "https://swapi.co/api/people/4/",
    "https://swapi.co/api/people/5/",
    "https://swapi.co/api/people/10/",
    "https://swapi.co/api/people/13/",
    "https://swapi.co/api/people/14/",
    "https://swapi.co/api/people/18/",
    "https://swapi.co/api/people/20/",
    "https://swapi.co/api/people/21/",
    "https://swapi.co/api/people/22/",
    "https://swapi.co/api/people/23/",
    "https://swapi.co/api/people/24/",
    "https://swapi.co/api/people/25/",
    "https://swapi.co/api/people/26/"
  ],
  "planets": [
        //... Long list of routes
    ],
  "starships": [
        //... Long list of routes
    ],
  "vehicles": [
        //... Long list of routes
    ],
  "species": [
        //... Long list of routes
    ],
  "created": "2014-12-12T11:26:24.656000Z",
  "edited": "2017-04-19T10:57:29.544256Z",
  "url": "https://swapi.co/api/films/2/"
  }

Wenn wir alle Figuren auflisten wollten, die in diesem Film vorkommen, müssten wir viel mehr Anfragen stellen. In diesem Fall müssten wir 16 weitere Routen ansteuern und 16 weitere Roundtrips zum Client machen. Jede HTTP-Anfrage verbraucht Client-Ressourcen und holt zu viele Daten ab. Das Ergebnis ist ein langsameres Nutzererlebnis, und Nutzer mit langsameren Netzwerkgeschwindigkeiten oder langsameren Geräten können die Inhalte möglicherweise gar nicht sehen.

Die GraphQL-Lösung für das Underfetching besteht darin, eine verschachtelte Abfrage zu definieren und die Daten dann in einem einzigen Fetch anzufordern, wie Abbildung 1-4 zeigt.

Abbildung 1-4. Folienverbindung

Hier erhalten wir nur die Daten, die wir in einer Anfrage benötigen. Und wie immer entspricht die Form der Abfrage der Form der zurückgegebenen Daten.

REST-Endpunkte verwalten

Ein weiterer häufiger Kritikpunkt an REST-APIs ist die mangelnde Flexibilität. Wenn sich die Anforderungen des Kunden ändern, musst du in der Regel neue Endpunkte erstellen, und diese Endpunkte können sich schnell vermehren. Um es mit den Worten von Oprah zu sagen: "Du bekommst eine Route! Du bekommst eine Route! Jeder! Körper! Gets! A! Route!"

Mit der SWAPI REST API mussten wir Anfragen an zahlreiche Routen stellen. Größere Anwendungen verwenden in der Regel benutzerdefinierte Endpunkte, um HTTP-Anfragen zu minimieren. Du wirst sehen, dass Endpunkte wie /api/character-with-movie-title auftauchen. Die Entwicklungsgeschwindigkeit kann langsam sein, weil das Einrichten neuer Endpunkte oft bedeutet, dass Frontend- und Backend-Teams mehr Planung und Kommunikation miteinander betreiben müssen.

Bei GraphQL besteht die typische Architektur aus einem einzigen Endpunkt. Der einzelne Endpunkt kann als Gateway fungieren und mehrere Datenquellen orchestrieren, aber der eine Endpunkt macht die Organisation der Daten einfacher.

Bei dieser Diskussion über die Nachteile von REST ist es wichtig zu wissen, dass viele Unternehmen GraphQL und REST gemeinsam nutzen. Das Einrichten eines GraphQL-Endpunkts, der Daten von REST-Endpunkten abruft, ist eine gute Möglichkeit, GraphQL zu nutzen. Das kann eine gute Möglichkeit sein, GraphQL schrittweise in deinem Unternehmen einzuführen.

GraphQL in der realen Welt

GraphQL wird von einer Vielzahl von Unternehmen genutzt, um ihre Apps, Websites und APIs zu betreiben. Einer der sichtbarsten frühen Anwender von GraphQL war GitHub, dessen REST-API drei Iterationen durchlief und dessen öffentliche API in Version 4 GraphQL verwendet. Wie es auf derWebsite heißt, hat GitHub festgestellt, dass "die Möglichkeit, genau die Daten zu definieren, die du willst - und nur die Daten, die du willst - ein großer Vorteil gegenüber den Endpunkten der REST API v3 ist.

Auch andere Unternehmen wie die New York Times, IBM, Twitter und Yelp setzen auf GraphQL, und Entwickler aus diesen Teams sind oft auf Konferenzen anzutreffen, um die Vorteile von GraphQL zu erläutern.

Es gibt mindestens drei Konferenzen, die sich speziell mit GraphQL beschäftigen: GraphQL Summit in San Francisco, GraphQL Finland in Helsinki und GraphQL Europe in Berlin. Die Gemeinschaft wächst weiter durch lokale Treffen und eine Vielzahl von Softwarekonferenzen.

GraphQL Klienten

Wie wir schon oft gesagt haben, ist GraphQL nur eine Spezifikation. Ihr ist es egal, ob du sie mit React oder Vue oder JavaScript oder sogar einem Browser verwendest. GraphQL hat Meinungen zu einigen spezifischen Themen, aber darüber hinaus sind deine architektonischen Entscheidungen dir überlassen. Das hat dazu geführt, dass Tools entstanden sind, die einige Entscheidungen über die Spezifikation hinaus erzwingen. Das sind die GraphQL-Clients.

GraphQL-Clients sind entstanden, um den Workflow für Entwicklerteams zu beschleunigen und die Effizienz und Leistung von Anwendungen zu verbessern. Sie übernehmen Aufgaben wie Netzwerkanfragen, Datencaching und das Einfügen von Daten in die Benutzeroberfläche. Es gibt viele GraphQL-Clients, aber die führenden in diesem Bereich sind Relay undApollo.

Relay ist der Facebook-Client, der mit React und React Native funktioniert. Relay ist das Bindeglied zwischen den React-Komponenten und den Daten, die vom GraphQL-Server abgerufen werden. Relay wird von Facebook, GitHub, Twitch und vielen anderen genutzt.

Apollo Client wurde von der Meteor Development Group entwickelt und ist ein von der Community vorangetriebenes Projekt, um ein umfassenderes Tooling für GraphQL zu entwickeln. Apollo Client unterstützt alle wichtigen Frontend-Entwicklungsplattformen und ist unabhängig von Frameworks. Apollo entwickelt auch Tools, die bei der Erstellung von GraphQL-Diensten, der Leistungsverbesserung von Backend-Diensten und der Überwachung der Leistung von GraphQL-APIs helfen. Unternehmen wie Airbnb, CNBC, The New York Times und Ticketmaster nutzen Apollo Client in der Produktion.

Das Ökosystem ist groß und verändert sich ständig, aber die gute Nachricht ist, dass die GraphQL-Spezifikation ein ziemlich stabiler Standard ist. In den nächsten Kapiteln werden wir besprechen, wie man ein Schema schreibt und einen GraphQL-Server erstellt. Im GitHub-Repository dieses Buches findest du Lernressourcen, die dich auf deinem Weg unterstützen: https://github.com/moonhighway/learning-graphql/. Dort findest du hilfreiche Links, Beispiele und alle Projektdateien nach Kapiteln geordnet.

Bevor wir uns mit den taktischen Aspekten der Arbeit mit GraphQL beschäftigen, sollten wir ein wenig über die Graphentheorie und die reiche Geschichte der GraphQL-Ideen sprechen.

¹ Siehe die GraphQL Server Libraries unter https://graphql.org/code/.

² Siehe die GraphQL Spec, Juni 2018.

³ Siehe "Data Fetching for React Applications" von Dan Schafer und Jing Chen, https://www.youtube.com/watch?v=9sc8Pyc51uU.

⁴ Beachte, dass in den SWAPI-Daten die neuesten Star Wars-Filme nicht enthalten sind.