Eine kurze Tour durch GraphQL

Hallo Habr!


Das Buch von Alex Banks und Eva Porsello, das wir vor einigen Tagen der Übersetzung gegeben haben, dient Ihnen als kurzer Exkurs in die GraphQL-Abfragesprache. Das Buch der gleichen Autoren über React und Redux wurde zu einem echten Bestseller (wir warten auf die 5. Auflage der Druckerei). Übrigens, danke an alle, die uns auf Ungenauigkeiten im Code und in den Begriffen hingewiesen haben;) Wir haben das Buch über so schnell veraltete Technologie zu schnell gemacht.

Der Autor des heutigen Artikels, Robin Viruch, arbeitet ebenfalls an einem Buch über GraphQL und Bibliotheken für diese Sprache und erklärt im heutigen Artikel kurz die Vorteile und Eigenschaften von GraphQL als Alternative zu REST



Wenn es um Netzwerkanforderungen zwischen Client- und Serveranwendungen geht, wird REST am häufigsten als Brücke zwischen der Client- und der Serverwelt ausgewählt. In REST dreht sich alles um die Idee "Wir brauchen Ressourcen, auf die über URL zugegriffen werden kann". Sie können eine Ressource mithilfe einer HTTP GET lesen, eine Ressource mithilfe einer HTTP POST Anforderung erstellen und sie mithilfe von HTTP PUT und DELETE Anforderungen aktualisieren und löschen. Diese Vorgänge werden als CRUD (Erstellen, Lesen, Aktualisieren, Löschen) bezeichnet. Die Ressource kann jeder Inhalt sein, der von Autoren, Benutzern oder aus Artikeln stammt. Bei Verwendung von REST ist das Datenübertragungsformat nicht fest codiert, aber meistens wird JSON für diesen Zweck verwendet. Am Ende ermöglicht REST die Kommunikation zwischen Anwendungen über das normale HTTP-Protokoll mithilfe von URLs und HTTP-Methoden.

 //    REST GET https://api.domain.com/authors/7 //   JSON { "id": "7", "name": "Robin Wieruch", "avatarUrl": "https://domain.com/authors/7", "firstName": "Robin", "lastName": "Wieruch" } 

Obwohl REST eine ganze Weile ein De-facto-Standard blieb, hat in den letzten Jahren eine andere von Facebook entwickelte Technologie an Popularität gewonnen: Sie heißt GraphQL. Dieser Artikel, eine Einführung in GraphQL, beschreibt die Vor- und Nachteile dieser Abfragesprache.

Was ist GraphQL?

Bevor wir uns mit den Stärken und Schwächen von GraphQL befassen, beantworten wir zunächst die folgende Frage: Was ist GraphQL? GraphQL ist eine Freeware- Abfragesprache, die 2012 von Facebook erstellt wurde. Bereits vor der Übermittlung des Produkts an Open Source wurde die Sprache auf Facebook als interne Technologie für die Arbeit mit mobilen Anwendungen verwendet. Warum mit mobilen Apps? GraphQL wurde als Alternative zur typischen REST-Architektur entwickelt. Der Client kann nur die gewünschten Daten anfordern - nicht mehr und nicht weniger. Der Kunde ist für alles verantwortlich, also für Sie. In diesem Fall treten Schwierigkeiten in der REST-Architektur auf, da die Datenbankschnittstelle bestimmt, welche Informationen für jede Ressource unter jeder URL verfügbar sind. Datenabtastung wird im Client-Teil nicht angefordert. Daher sollte das Frontend auf jeden Fall alle Informationen über die Ressource anfordern, auch wenn es nur einen Teil dieser Daten benötigt. Dieses Problem wird als "erneutes Abtasten" bezeichnet. Im schlimmsten Fall muss die Clientanwendung nicht nur eine, sondern viele Ressourcen lesen, für deren Zugriff viele Netzwerkanforderungen ausgeführt werden müssen. Dies führt nicht nur zu einer erneuten Probenahme, sondern auch zu Lawinenanforderungen über das Netzwerk. Mit einer Abfragesprache wie GraphQL, die nicht nur auf dem Server, sondern auch auf der Clientseite verwendet wird, entscheidet der Client, welche Daten er benötigt - und sendet dafür nur eine Anfrage an den Server. Als Facebook mobile Anwendungen mit der GraphQL-Sprache entwickelte, konnte die Netzwerklast drastisch reduziert werden, da viel weniger Daten über Facebook übertragen wurden.

Facebook hat die GraphQL-Spezifikation und ihre Referenzimplementierung in JavaScript für den freien Zugriff veröffentlicht. Seitdem wurde diese Spezifikation in vielen anderen wichtigen Programmiersprachen implementiert. Darüber hinaus wächst das Ökosystem, das sich um GraphQL herum entwickelt hat, nicht nur horizontal und breitet sich auch auf andere Programmiersprachen aus, sondern auch vertikal (Bibliotheken bauen auf GraphQL auf, z. B. Apollo, Relay).

GraphQL bietet die folgenden Arten von Operationen: Anforderung (Lesen), Ändern (Schreiben) oder Abonnement (kontinuierliches Lesen). Jede dieser Operationen ist nur eine Zeichenfolge, die gemäß der Spezifikation der GraphQL-Abfragesprache zusammengestellt werden muss. Sobald eine solche GraphQL-Operation von der Client-Anwendung zur Datenbankanwendung gelangt, kann sie im Vergleich zum gesamten GraphQL-Schema im Backend interpretiert und für die Client-Anwendung unter Verwendung der verfügbaren Daten zugelassen werden. GraphQL funktioniert mit jeder Netzwerkschicht (die häufig über HTTP organisiert ist) ebenso gut wie mit jedem Nutzdatenformat (häufig JSON). Er befasst sich auch vollständig nicht mit der Anwendungsarchitektur (die in den meisten Fällen aus dem Client-Teil und der Datenbankschnittstelle besteht). Es ist nur eine Abfragesprache.

 //  GraphQL author(id: "7") { id name avatarUrl articles(limit: 2) { name urlSlug } } //   GraphQL { "data": { "author": { "id": "7", "name": "Robin Wieruch", "avatarUrl": "https://domain.com/authors/7", "articles": [ { "name": "The Road to learn React", "urlSlug": "the-road-to-learn-react" }, { "name": "React Testing Tutorial", "urlSlug": "react-testing-tutorial" } ] } } } 

Wie Sie sehen können, gilt die Abfrage bereits für viele Ressourcen (Autor, Artikel), die in GraphQL als Felder bezeichnet werden, und nur für einen bestimmten Satz verschachtelter Felder für diese Felder (Name, URLSlug für den Artikel), obwohl andere Daten im GraphQL-Datenschema selbst bereitgestellt werden können Informationen (zum Beispiel für einen Artikel - eine Beschreibung, Erscheinungsdatum). Während in einer REST-Architektur mindestens zwei kaskadierende Abfragen erforderlich sind, um den Autor und die Artikel dieses Autors abzurufen, löst GraphQL dieses Problem in einer Abfrage. Darüber hinaus wählt die Abfrage nur die erforderlichen Felder und nicht die gesamte Entität aus.

Dies ist die Essenz von GraphQL. In dem Fall, in dem die Serveranwendung das GraphQL-Schema bereitstellt, in dem sie alle verfügbaren Daten mit ihrer Hierarchie und ihren Typen definiert, fordert die Clientanwendung nur die Daten an, die sie benötigt.

GraphQL-Vorteile

Im Folgenden sind die Hauptvorteile der Verwendung von GraphQL in einer Anwendung aufgeführt.

Deklarative Datenerfassung

Wie Sie sehen können, verwendet GraphQL in seinen Abfragen deklarative Datenstichproben. Der Client wählt die Daten, ihre Entitäten und alle Felder aus, zwischen denen verschiedene Beziehungen bestehen, und für all dies wird eine einzelne Anforderung angewendet. Der Client entscheidet, welche Felder für diese Benutzeroberfläche benötigt werden. Oft kann man fast über UI-orientierte Datenerfassung sprechen. So verwendet Airbnb beispielsweise GraphQL. Eine Airbnb-Suchmaschine liefert häufig Ergebnisse für Häuser, Impressionen und andere Kategorien, die für einen bestimmten Themenbereich spezifisch sind. Um alle Daten auf einmal zu extrahieren, wird eine GraphQL-Abfrage ausgeführt, die nur die Informationen aufnimmt, die in einer bestimmten Benutzeroberfläche definitiv benötigt werden. Letztendlich hat GraphQL eine sehr gut organisierte Aufgabenteilung: Der Client kennt die Datenanforderungen, der Server kennt die Datenstruktur und weiß, wie Daten aus einer vorhandenen Quelle aufgelöst werden (sei es eine Datenbank, ein Microservice oder eine Drittanbieter-API).

Kein erneutes Abtasten bei der Arbeit mit GraphQL

Bei der Arbeit mit GraphQL erfolgt keine erneute Auswahl. Während ein mobiler Client wahrscheinlich einen erneuten Abruf mit derselben API wie ein Webclient mit einer REST-API durchführt. Bei der Arbeit mit GraphQL können der mobile Client und der Webclient mithilfe derselben GraphQL-API unterschiedliche Feldgruppen für sich auswählen. Folglich kann der mobile Client weniger Informationen auswählen, da auf dem kleinen Bildschirm möglicherweise keine unnötigen Informationen benötigt werden (im Gegensatz zu dem großen Monitor, von dem aus die Webversion der Anwendung angezeigt wird). GraphQL minimiert die über das Netzwerk übertragene Datenmenge, wählt sie selektiv aus und orientiert sich in diesem Fall in erster Linie an den Anforderungen der Clientanwendung.

GraphQL für React, Angular, Node usw.

GraphQL ist eine vielversprechende Lösung nicht nur für React-Entwickler. Sei es Facebook, das GraphQL übertrumpft, und auf der Client-Seite verwendet Facebook React. Tatsächlich ist diese Sprache an keine Lösung für das Frontend oder Backend gebunden. Die Referenzimplementierung von GraphQL ist in JavaScript geschrieben, sodass GraphQL mit Angular-, Vue-, Express-, Hapi-, Koa- und anderen JavaScript-Bibliotheken in den Client- und Serverteilen kombiniert werden kann. Darüber hinaus gilt dies nicht nur für das JavaScript-Ökosystem. GraphQL imitiert REST in einem Aspekt, aufgrund dessen es populär geworden ist: Die GraphQL-Schnittstelle ist unabhängig von der Programmiersprache (Abfragesprache), die zur Kommunikation von zwei Objekten (z. B. Client und Server) verwendet wird. Daher kann seine Spezifikation in jeder Programmiersprache reproduziert werden.

Wer nutzt GraphQL?

Facebook verwendet GraphQL seit 2012, bevor diese Sprache Open Source wurde. Facebook ist die treibende Kraft für die Entwicklung der GraphQL-Spezifikation und deren Referenzimplementierung in JavaScript. Wenn Sie also mit GraphQL arbeiten, stehen Sie bereits auf den Schultern von Riesen. Andere bekannte Unternehmen verwenden diese Sprache jedoch in ihren Anwendungen. Sie investieren in das GraphQL-Ökosystem, weil moderne Anwendungen eine solche Sprache dringend benötigen. Sie werden also nicht nur von Facebook unterstützt, sondern auch von folgenden Unternehmen:


Als Facebook GraphQL entwickelte und öffentlich zugänglich machte, standen auch andere Unternehmen für mobile Apps vor ähnlichen Problemen. Auf diese Weise hat Netflix das Falcor-Projekt erstellt, das als Alternative zu GraphQL angesehen werden kann. Dies bestätigt einmal mehr, dass Sie für moderne Anwendungen genau solche Lösungen wie GraphQL und Falcor benötigen.

Die eine Quelle der Wahrheit

In GraphQL-Anwendungen existiert die ultimative Wahrheit: Dies ist das GraphQL-Schema. Sie ist es - die zentrale Quelle, die alle verfügbaren Daten beschreibt. Während das GraphQL-Schema normalerweise auf der Serverseite definiert wird, können Clients Daten basierend auf diesem Schema lesen (abfragen) und schreiben (ändern). Daher stellt die Serveranwendung im Wesentlichen die auf dem Server verfügbaren umfassenden Informationen bereit, und die Clientseite fragt nur, was für die Formulierung von Abfragen in GraphQL erforderlich ist, oder ändert kleine Informationsfragmente mithilfe der Änderungen in GraphQL.

GraphQL folgt aktuellen Trends

GraphQL folgt aktuellen Trends in der Anwendungsentwicklung. Sie können nur eine Anwendung im Backend haben, aber es kommt häufig vor, dass viele verschiedene Clients dieses Backend verwenden (Webclient, Mobilgerät, Smartwatches ...) und alle von den in der Backendanwendung gespeicherten Daten abhängen. Daher kann GraphQL nicht nur dazu beitragen, Freunde aus beiden Welten zu finden, sondern auch die Anforderungen jedes Clients zu erfüllen (z. B. über das Netzwerk, verschachtelte Datenbeziehungen, nur die erforderlichen Daten auswählen), ohne dass für jeden Client-Typ eine dedizierte API erstellt werden muss.

Andererseits können wir auf dem Server keine einzige interne Schnittstelle erwarten, sondern eine Gruppe von Mikrodiensten, von denen jeder seine eigene spezifische Funktionalität bietet. Für einen solchen Fall ist das GraphQL-Schema ideal geeignet, dessen Struktur so ist, dass in einem solchen GraphQL-Schema alle Arten von Funktionen aggregiert werden können.

Wie das GraphQL-Schema sticht

Dank des Nähens können Sie ein Schema aus vielen anderen zusammensetzen. Wann kann ich in diese Situation geraten? Angenommen, Ihr Backend wird mithilfe einer Microservice-Architektur implementiert. Jeder Microservice verarbeitet Geschäftslogik und Daten zu einem bestimmten Themenbereich. Daher kann jeder Mikrodienst sein eigenes GraphQL-Schema definieren. Danach müssen Sie sie zusammennähen, um eines der Schemata zusammenzustellen, auf die die Clientanwendung zugreifen wird. Am Ende kann jeder Mikrodienst ein eigenes GraphQL-Terminal haben, und ein GraphQL-API-Gateway konsolidiert alle Schemata in einem globalen, um es für Clientanwendungen bereitzustellen.

Introspection GraphQL

GraphQL Introspection ist die Fähigkeit, ein GraphQL-Schema mit der GraphQL-API zu extrahieren. Da das Schema alle Informationen zu allen über die GraphQL-API verfügbaren Daten enthält, kann es mit großem Erfolg für die automatische Generierung der API-Dokumentation verwendet werden. Die Angelegenheit ist jedoch nicht auf die Dokumentation der API beschränkt. Introspection kann auch verwendet werden, um GraphQL-Schemas in einer Client-Anwendung zu simulieren (zu Testzwecken) oder um Schemas von mehreren Microservices abzurufen und sie dann zusammenzufügen.

Stark typisiertes GraphQL

GraphQL ist eine stark typisierte Abfragesprache, die in der ausdrucksstarken Schema Definition Language (SDL) für GraphQL geschrieben ist. Diese Sprache hat die gleichen Vorteile wie jede stark typisierte Programmiersprache. Es ist weniger fehleranfällig, kann zur Kompilierungszeit validiert werden und kann für die Integration in unterstützte IDE / Editor-Funktionen wie Autovervollständigung und Eingabeunterstützung verwendet werden.

Versionierung von GraphQL

GraphQL verfügt nicht über solche API-Versionen, die wir in REST gewohnt sind. In REST ist es normal, mehrere Versionen derselben API anzubieten (z. B. api.domain.com/v1/, api.domain.com/v2/), da sich Ressourcen oder ihre Struktur im Laufe der Zeit ändern können. In GraphQL können Sie APIs auf Feldebene in nicht empfohlene APIs übersetzen. Daher erhält der Client eine Warnung, wenn er auf ein nicht empfohlenes Feld zugreift. Nach einiger Zeit kann das nicht empfohlene Feld aus dem Schema ausgeschlossen werden, dann wird es von keinen Clients mehr verwendet. Somit kann die GraphQL-API entwickelt werden, ohne dass eine Versionierung erforderlich ist.

Wachsendes GraphQL-Ökosystem

Das GraphQL-Ökosystem wächst. Es geht nicht nur um Integrationen mit Editoren und IDEs, die mit der stark typisierten Natur von GraphQL zusammenhängen. Für GraphQL als solches gibt es neue vollwertige Anwendungen. Sie können sich beispielsweise an Postman erinnern, das bei der Arbeit mit der REST-API verwendet wurde und jetzt für denselben Zweck, jedoch mit der GraphQL-API, GraphiQL oder GraphQL Playground verwendet wird. Es gibt auch verschiedene Bibliotheken für Sie, zum Beispiel Gatsby.js, einen statischen Website-Generator für React, der GraphQL verwendet. Mit Gatsby.js können Sie beispielsweise eine Blog-Engine schreiben, die Ihr Blog während der Erstellung über die GraphQL-API mit Inhalten füllt. Daher verfügen Sie auch über CMS ohne Client-Teil (z. B. GraphCMS), der Inhalte (für ein Blog) über GraphQL bereitstellt. API In diesem Bereich entwickeln sich jedoch nicht nur technologische Komponenten. Da nach dem Regen Pilze wachsen, sind Konferenzen, Mitaps und Communities, die sich GraphQL widmen, auch in Newslettern und Podcasts leicht zu finden.

Wenn ich zu GraphQL wechsle - gehe ich All-In?

Wenn wir GraphQL zum vorhandenen technologischen Stack hinzufügen, gehen wir natürlich nicht all-in. Bei der Migration von einer monolithischen Back-End-Anwendung zu einer Microservice-Architektur ist es am wichtigsten, neue Microservices durch die GraphQL-API zu ersetzen. Genau in Gegenwart vieler Microservices können Sie und Ihr Team das GraphQL-Gateway sicher implementieren, Schemata zusammenfügen und zu einem globalen Schema zusammenfassen. Das API-Gateway kann jedoch nicht nur mit Microservices, sondern auch mit einer monolithischen REST-Anwendung verwendet werden. Auf diese Weise können Sie alle Ihre APIs auf einem Gateway kombinieren und Schritt für Schritt auf GraphQL migrieren.

Nachteile von GraphQL

Als nächstes diskutieren wir einige der Nachteile, die mit der Verwendung von GraphQL verbunden sind.

GraphQL-Abfragekomplexität

Manchmal wird GraphQL falsch verwendet, ich versuche es durch eine serverseitige Datenbank zu ersetzen. Nein, das geht nicht. GraphQL ist nur eine Abfragesprache. Wenn auf der Serverseite die Anforderung mit Daten aufgelöst werden muss, gibt es normalerweise eine GraphQL-unabhängige Implementierung, die den Zugriff auf die Datenbank ermöglicht. GraphQL ist in diesem Fall gleichgültig. Darüber hinaus beseitigt GraphQL keine Leistungsengpässe, wenn Sie viele Felder (Autoren, Artikel, Kommentare) in einer Abfrage behandeln müssen. Unabhängig von der Architektur, in der die Anforderung gestellt wurde - RESTful oder GraphQL - müssen Sie immer noch verschiedene Felder aus der Quelle extrahieren.

Daher tritt ein Problem auf, wenn der Client eine Reihe von Anforderungen sofort an die verschachtelten Felder sendet. Häufig wissen die clientseitigen Entwickler nicht, wie viele verschiedene Datenbankabfragen in der Serveranwendung verarbeitet werden müssen, wenn Massendatenaufrufe beginnen. In solchen Fällen ist ein Mechanismus erforderlich (z. B. maximale Abfragetiefe, Gewichtung der Komplexität von Abfragen, Vermeidung von Rekursionen, konstante Abfragen), um den Fluss zu teurer Abfragen vom Client zu verhindern.

Geschwindigkeitsbegrenzung in GraphQL

Ein weiteres Problem ist die Geschwindigkeitsbegrenzung. Während in REST relativ einfach zu sagen ist, dass nicht mehr als so viele Abfragen pro Tag zulässig sind, ist es schwierig, eine solche Anweisung für einzelne GraphQL-Operationen zu formulieren, da es nicht nur "kostspielige" und "nicht kostspielige" Operationen gibt, sondern auch viele Zwischenabstufungen. In solchen Fällen bieten Unternehmen, die öffentliche GraphQL-APIs bereitstellen, ihre eigenen Geschwindigkeitsbegrenzungsberechnungen an , die häufig auf die oben genannten Maximalwerte für die Abfragetiefe und die Gewichtung der Abfragekomplexität reduziert werden.

GraphQL-Caching

Bei der Arbeit mit GraphQL ist die Implementierung eines vereinfachten Caches viel komplizierter als in REST. Bei der Arbeit mit REST greifen wir über die URL auf Ressourcen zu und können daher das Caching auf Ressourcenebene organisieren, da die Ressourcen-URL als Kennung dienen kann. In GraphQL ist dies kompliziert, da alle Abfragen unterschiedlich sein können, obwohl alle mit demselben Objekt arbeiten. In einer Anfrage können Sie den Namen des Autors und in der nächsten nicht nur den Namen des Autors, sondern auch seine E-Mail-Adresse anfordern. In solchen Fällen benötigen Sie einen filigraneren Cache auf Feldebene, und die Implementierung ist nicht so einfach. Die meisten Bibliotheken, die auf GraphQL aufbauen, bieten solche Caching-Mechanismen jedoch sofort an.

Warum nicht REST?

GraphQL – REST, . REST – GraphQL, REST?
REST URL , . «», id, , id. GraphQL , . , , , GraphQL , .

, REST. Airbnb. , . REST-, REST- . , , GraphQL API, GraphQL, (, ), (., ).

, GraphQL ; , , , . GraphQL – Facebook , -.

, , REST – . , GraphQL. , GraphQL, - .

Source: https://habr.com/ru/post/de424037/


All Articles