Meeting GraphQL At A Cocktail Mixer

GraphQL und REST sind zwei Spezifikationen, die beim Erstellen von APIs für Websites verwendet werden. REST definiert eine Reihe von eindeutigen Bezeichnern (URLs), die Anwendungen zum Anfordern und Senden von Daten verwenden. GraphQL definiert eine Abfragesprache, mit der Client-Anwendungen genau die Daten angeben können, die sie von einem einzelnen Endpunkt benötigen. Es handelt sich um verwandte Technologien, die für weitgehend dieselben Zwecke verwendet werden (tatsächlich können und existieren sie oft nebeneinander), aber sie sind auch sehr unterschiedlich.

Das ist ein bisschen trocken, oder? Lass es uns auf eine viel unterhaltsamere Weise erklären, die dir vielleicht hilft, es besser zu verstehen und dich vielleicht sogar ein wenig für GraphQL zu begeistern!

🍹 Du bist auf einem Cocktail-Treffen

Du besuchst dieses Treffen, um dein berufliches Netzwerk aufzubauen, daher möchtest du natürlich Daten über die Leute um dich herum sammeln. In deiner Nähe sind fünf weitere Teilnehmer.

Ihre Namensschilder lauten

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

Als das dynamische, soziale, aufgeschlossene Tier, das du bist, gehst du direkt auf Richy REST zu und sagst: „Hallo, ich bin Adam Application, wer bist du?“ Richy REST antwortet

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

„Wow, das war viel auf einmal“, denkst du dir. Um peinliche Stille zu vermeiden, erinnerst du dich, dass Richy REST erwähnt hat, dass er angestellt ist, und fragst: „Wo arbeitest du?“

Seltsamerweise hat Richy REST keine Ahnung, wo er arbeitet. Vielleicht weiß es der Arbeitgeber von Richy REST?

Du stellst dieselbe Frage dem Arbeitgeber von Richy REST, der sich freut, deine Anfrage zu beantworten! Er antwortet wie folgt

{
  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
}

An diesem Punkt bist du erschöpft. Du hast nicht einmal mehr Lust, den Freund von Richy REST kennenzulernen! Das könnte ewig dauern, deine ganze Energie aufbrauchen und du hast keine Zeit.

Georgia GraphQL steht jedoch höflich da, also beschließt du, sie anzusprechen.

„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 GraphQL ist unglaublich, artikuliert, prägnant und auf den Punkt gebracht. Du möchtest zu 100 % Visitenkarten austauschen und bei zukünftigen Projekten mit Georgia zusammenarbeiten.

Diese Anekdote verkörpert die Erfahrung von Entwicklern, die mit GraphQL gegenüber REST arbeiten. GraphQL ermöglicht es Entwicklern, mit einer ordentlichen Abfrage zu artikulieren, was sie wollen, und als Antwort nur das zu erhalten, was sie spezifiziert haben. Diese Abfragen sind voll dynamisch, sodass nur ein einziger Endpunkt benötigt wird. REST hingegen hat vordefinierte Antworten und erfordert oft, dass Anwendungen mehrere Endpunkte nutzen, um einen vollständigen Datenbedarf zu decken.

Metapher vorbei! Reden wir Klartext.

Um die wesentlichen Konzepte der Cocktail-Treffen-Metapher weiter zu erläutern, wollen wir zwei Einschränkungen ansprechen, die bei der Verwendung von REST häufig auftreten.

1. Mehrere Abrufe beim Abrufen verwandter Ressourcen

Datengetriebene mobile und Webanwendungen erfordern oft verwandte Ressourcen und Datensätze. Daher kann das Abrufen von Daten über eine REST-API mehrere Anfragen an zahlreiche Endpunkte umfassen. Zum Beispiel kann das Abrufen einer Post-Entität und des zugehörigen Autors durch zwei Anfragen an verschiedene Endpunkte erfolgen.

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

Mehrere Abrufe einer API beeinträchtigen die Leistung und Bereitschaft einer Anwendung. Dies ist auch ein größeres Problem für Geräte mit geringer Bandbreite (z. B. Smartwatches, IoT, ältere mobile Geräte und andere).

2. Über- und Unter-Fetching

Über-/Unter-Fetching ist bei RESTful APIs unvermeidlich. Am obigen Beispiel zeigt der Endpunkt domainName.com/posts/:id Daten für einen bestimmten Post an. Jeder Post besteht aus Attributen wie id, body, title, publishingDate, authorId und anderen. In REST wird immer dasselbe Datenobjekt zurückgegeben; die Antwort ist vordefiniert.

In Situationen, in denen nur ein Post-Titel und -Body benötigt werden, tritt Über-Fetching auf – da mehr Daten über das Netzwerk gesendet werden, als tatsächlich genutzt werden. Wenn ein gesamter Post zusammen mit verwandten Daten über seinen Autor benötigt wird, tritt Unter-Fetching auf – da weniger Daten über das Netzwerk gesendet werden, als tatsächlich genutzt werden. Unter-Fetching führt zu einer Überlastung der Bandbreite durch mehrere Anfragen an die API.

Clientseitige Abfragen mit GraphQL

GraphQL führt einen wirklich einzigartigen Ansatz ein, der Client-Apps ein enormes Maß an Flexibilität bietet. Mit GraphQL wird eine Abfrage an Ihre API gesendet und genau das zurückgegeben, was Sie benötigen – nicht mehr und nicht weniger – in einer einzigen Anfrage. Abfrageergebnisse werden in derselben Form wie Ihre Abfrage zurückgegeben, wodurch sichergestellt wird, dass die Antwortstrukturen immer vorhersagbar sind. Diese Faktoren ermöglichen es Apps, schneller und stabiler zu laufen, weil *sie* die Kontrolle über die von ihnen erhaltenen Daten haben und nicht der Server.

„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ätscheck ✅

Nun, an diesem Punkt denkst du wahrscheinlich, dass GraphQL so einfach ist wie das Schneiden von warmer Butter mit einem Samuraischwert. Das mag für Front-End-Entwickler Realität sein – insbesondere für Entwickler, die GraphQL-APIs nutzen. Wenn es jedoch um die serverseitige Einrichtung geht, muss jemand die Wurst machen. Unsere Freundin Georgia GraphQL hat harte Arbeit geleistet, um die fantastische Fachkraft zu werden, die sie ist!

Der Aufbau einer GraphQL-API, serverseitig, ist etwas, das Zeit, Energie und Fachwissen erfordert. Allerdings ist es nichts, was jemand, der für eine Herausforderung bereit ist, nicht bewältigen kann! Es gibt viele verschiedene Möglichkeiten, auf allen Abstraktionsebenen einzusteigen. Zum Beispiel

Ungehindert: Wenn du wirklich deine Hände schmutzig machen willst, versuche, eine GraphQL-API mit Hilfe von Paketen zu erstellen. Wenn du zum Beispiel Rails magst? Schau dir graphql-ruby an. Liebst du Node.js? Probiere express-graphql.
Unterstützt: Wenn die vollständige Wartung deines Servers/Self-Hostings Priorität hat, kann dir etwas wie Graph.cool helfen, mit einem GraphQL-Projekt loszulegen.
Sofort: Keine Lust mehr auf CRUD-Boilerplate-Code und möchtest schnell loslegen? 8base bietet eine sofort einsatzbereite GraphQL-API und ein serverloses Backend, das vollständig erweiterbar ist.

Zusammenfassung

REST war ein bedeutender Fortschritt für Webdienste, um hochverfügbare ressourcenspezifische APIs zu ermöglichen. Sein Design berücksichtigte jedoch nicht die heutige Verbreitung vernetzter Geräte mit unterschiedlichen Datenbeschränkungen und -anforderungen. Dieses Versäumnis hat schnell zur Verbreitung von GraphQL – 2015 von Facebook als Open Source veröffentlicht – geführt, wegen der enormen Flexibilität, die es Front-End-Entwicklern bietet. Die Arbeit mit GraphQL ist eine fantastische Entwicklererfahrung, sowohl für einzelne Entwickler als auch für Teams.