Einführung von GraphQL auf einer Party

GraphQL und REST sind zwei Paradigmen zum Erstellen von APIs für Webanwendungen.

REST ist eine Reihe eindeutiger Kennungen (URLs), mit denen Anwendungen Daten anfordern und senden.

GraphQL ist eine Abfragesprache, mit der Clientanwendungen die benötigten Daten von einem einzelnen Endpunkt aus genau angeben können.

Dies sind verwandte Technologien, sie werden hauptsächlich für die gleichen Dinge verwendet (oder sie können koexistieren), aber sie sind sehr unterschiedlich.

Klingt ein bisschen frisch, oder? Lassen Sie uns ihre Unterschiede auf eine interessantere Art und Weise erklären, die Ihnen helfen kann, GraphQL besser zu verstehen und es vielleicht nur zu amüsieren.

Bist du auf einer Cocktailparty?

Du bist zur Party gekommen, um dich zu vernetzen, also brauchst du Informationen über die Menschen um dich herum. In der Nähe gibt es fünf weitere Gäste.

Ihre Namensschilder lauten wie folgt:

Richy REST
Freund von Richy REST
Arbeitgeber von Richy REST
Georgia GraphQL

Als aktiver und geselliger Partygänger gehen Sie direkt zu Richie Rest und sagen: "Hallo, ich bin Adam Epilation, und wer sind Sie?" Die Antwort von Richie Resta lautet:

{ name: "Richy REST", age: 33, married: false, hometown: "Circuits-ville", employed: true // ... 20 other things about Richy REST } 

Sie dachten sich: "Wow, sofort zu viele Informationen." Um unangenehme Stille zu vermeiden, erinnern Sie sich, dass Richie Rest erwähnt hat, dass er arbeitet, und Sie fragen: „Wo arbeiten Sie?“

Überraschenderweise hat Richie Rest keine Ahnung, wo er arbeitet. Vielleicht Arbeitgeber Richie Resta im Wissen?

Sie stellen die gleiche Frage an Arbeitgeber Ritchie Resta, der gerne Ihre Frage beantwortet:

 { company: "Mega Corp", employee_count: 11230, head_quarters: "1 Main Avenue, Big City, 10001, PL" year_founded: 2005, revenue: 100000000, // ... 20 other things about Richy REST Employer } 

Zu diesem Zeitpunkt sind Sie bereits erschöpft. Du willst nicht einmal einen Freund von Richie Resta treffen! Es kann ewig dauern, all deine Energie verschwenden und außerdem hast du keine Zeit mehr.

Georgia GrafKewel steht jedoch ganz in der Nähe und Sie beschließen, mit ihr zu plaudern.

"Hallo, wie heißt du?"

 { name: "Georgia GraphQL" } 

"Woher kommst du und wie alt bist du?"

 { hometown: "Pleasant-Ville", age: 28 } 

"Wie viele Hobbys und Freunde hast du und wie heißen deine Freunde?"

 { hobbies_count: 12, friends_count: 50, friends: [ { name: "Steve" }, { name: "Anjalla" }, // ...etc ] } 

Georgia GrafKewEl ist unglaublich, artikuliert klar, präzise und genau. Sie möchten auf jeden Fall Visitenkarten mit ihr austauschen und gemeinsam an zukünftigen Projekten arbeiten.

Diese Geschichte enthält die Erfahrung von Entwicklern, die mit GraphQL und REST arbeiten. Mit GraphQL können Entwickler mit einer übersichtlichen Abfrage formulieren, was sie wollen, und nur das erhalten, was sie als Antwort angeben. Diese Abfragen sind dynamisch, sodass nur ein Endpunkt erforderlich ist. Im Gegensatz dazu hat REST vordefinierte Antworten und erfordert, dass Anwendungen mehrere Endpunkte verwenden, um die Daten vollständig abzufragen.

Beenden Sie mit den Metaphern. Kommen wir zur Sache

Zur weiteren Offenlegung der in der Parteimetapher dargestellten Konzepte wenden wir uns speziell zwei Einschränkungen zu, die häufig bei der Verwendung von REST auftreten.

1. Mehrere Treffer beim Abrufen verwandter Ressourcen

Die Datenverwaltung für Mobil- und Webanwendungen erfordert häufig verwandte Ressourcen und Datensätze. Das Abrufen von Daten mithilfe der REST-API kann daher zahlreiche Anforderungen für mehrere Endpunkte nach sich ziehen. Beispielsweise kann eine Post-Anfrage und der zugehörige Autor durch zwei Anfragen an verschiedene Endpunkte gestellt werden:

 someServer.com/authors/:id someServer.com/posts/:id 

Wiederholte Aufrufe der API wirken sich auf die Anwendungsleistung aus. Dies ist umso wichtiger für Geräte mit geringer Bandbreite (z. B. Smartwatches, IoT, alte mobile Geräte usw.).

2. Über- und Unterabruf

Über- und Unterabruf ist bei Verwendung der RESTful-API unvermeidlich. Im obigen Beispiel ruft der Endpunkt domainName.com/posts/:id Daten für einen bestimmten Datensatz ab. Jeder Eintrag besteht aus Attributen wie ID, Text, Titel, Veröffentlichungsdatum, Autor-ID und anderen. In REST ist eine Antwort vordefiniert und es wird immer dasselbe Datenobjekt zurückgegeben.

In Situationen, in denen nur der Titel und der Text der Aufzeichnung erforderlich sind, erfolgt ein Überabruf, da mehr Daten über das Netzwerk gesendet werden, als tatsächlich verwendet werden.

Wenn eine gesamte Veröffentlichung zusammen mit zugehörigen Daten über den Autor erforderlich ist, wird nicht ausreichend abgerufen, da weniger Daten über das Netzwerk gesendet werden, als tatsächlich verwendet werden. Unzureichendes Unterabrufen von Daten führt zu einer Zunahme der Anzahl von API-Anforderungen und infolgedessen zu einer übermäßigen Nutzung von Internetressourcen.

Client-Abfragen mit GraphQL

GraphQL stellt einen einzigartigen Ansatz dar, der Clientanwendungen eine enorme Flexibilität bietet. Mit GraphQL wird die Abfrage an Ihre API gesendet und genau das, was Sie benötigen, wird in einer Abfrage zurückgegeben - nicht mehr und nicht weniger. Die Abfrageergebnisse werden in derselben Form wie die Abfrage selbst zurückgegeben, um sicherzustellen, dass die Antwortstruktur immer vorhersehbar ist. Diese Faktoren ermöglichen es Anwendungen, schneller und stabiler zu laufen, da sie die empfangenen Daten und nicht den Server steuern.

"Die Ergebnisse werden in derselben Form wie Abfragen zurückgegeben."

 /* Query */ { myFriends(first: 2) { items { name age } } } 

 /* Response */ { "data": { "items": [ { "name": "Steve", "age": 27 }, { "name": "Kelly", "age": 31 } ] } } 

Realitätsprüfung

Jetzt denken Sie wahrscheinlich, dass die Arbeit mit GraphQL so einfach ist wie das Hacken von warmer Butter mit einem Samuraischwert. Dies gilt möglicherweise für Front-End-Entwickler. Bei der Konfiguration der Serverseite muss jedoch jemand die schwierigste Arbeit leisten. Unsere Freundin Georgia GrafKewEl hat sich sehr bemüht, ein klassischer Profi zu werden.

Das Erstellen der serverseitigen GraphQL-API erfordert Zeit, Mühe und Erfahrung. Dennoch können diejenigen, die zum Testen bereit sind, damit umgehen. Es gibt viele verschiedene Möglichkeiten, dies zu tun, zum Beispiel:

Allein: Wenn Sie wirklich alles selbst erledigen möchten, erstellen Sie die GraphQL-API mit Paketen. Schienen benutzen? Versuchen Sie es mit graphql-ruby. Liebe Node.js? Versuchen Sie es mit express-graphql.

Mit : Wenn flexibles Hosting-Setup Ihre Priorität ist, kann Ihnen Graph.cool beim Einstieg in das GraphQL-Projekt helfen.

Sofort : Sind Sie es leid, eine CRUD-Vorlage zu schreiben, und möchten Sie schnell loslegen? 8base bietet eine sofortige GraphQL-API und ein Server-Backend, das erweitert werden kann.

Abschließend

Für Webdienste war REST ein bedeutender Schritt nach vorne, da es einfach war, APIs für den Zugriff auf die erforderlichen Ressourcen zu erstellen. Das Design berücksichtigte jedoch nicht die derzeitige Verbreitung mobiler Geräte mit verschiedenen Einschränkungen hinsichtlich des Datendownloadvolumens und der Anforderungen. Diese Auslassung führte zu einer wachsenden Beliebtheit von GraphQL, das Facebook 2015 als Open Source-Version eingeführt hat, vor allem aufgrund der Flexibilität, die es Front-End-Entwicklern bietet. Die Arbeit mit GraphQL ist sowohl für einzelne Entwickler als auch für Teams eine fantastische Erfahrung.