GraphQL: ist es der REST-API-Killer”?

Nach der Implementierung der GraphQL-Unterstützung in Parse haben mich viele Leute mit einigen Fragen erreicht, einige von ihnen machten sich Sorgen über die Zukunft der REST-API.
Wird GraphQL sie “töten”?
Was wird mit meinen REST-API-Methoden geschehen? Muss ich meinen Code neu schreiben?

In diesem Artikel werde ich diese Fragen behandeln, aber die kurze Antwort lautet: Nein, Sie müssen sich keine Sorgen machen, denn GraphQL wird REST API nicht “töten” und Sie müssen sich auch keine Sorgen machen, dass Sie Ihre bereits funktionierenden REST API-Methoden umschreiben müssen.

Was hat es also mit GraphQL auf sich?

Ein Missverständnis, das die meisten Leute, die mich erreichen, haben, ist, dass GraphQL nicht dazu da ist, das gesamte Backend zu ersetzen.

GraphQL wird das Backend nicht ersetzen. Auch nicht das Frontend.

GraphQL ist eine Abfragesprache, eine Möglichkeit für Sie, für Ihre API zu spezifizieren, nach welchen Informationen Sie suchen, und eine Laufzeit, die diese Informationen aus Ihren bereits vorhandenen Daten abruft.

Es ist einfach ein anderer Weg (ein besserer Weg, würde ich sagen), Ihrer App genau mitzuteilen, was Sie wissen müssen, und dann diese Informationen zu erhalten.

Sie müssen sich keine Sorgen um Ihre bereits vorhandenen und funktionierenden REST-API-Methoden machen. Sie werden weiterhin wie bisher funktionieren, auch wenn Sie GraphQL einführen. Das Einzige, was zu beachten ist, ist, dass GraphQL nur auf Parse 3.5.0 und höher läuft. Wenn Sie also von Parse 2.x oder älter kommen, bedeutet das auch eine Änderung der Codestruktur von Parse.

Wenn Sie also Parse 3.0 oder älter verwenden, brauchen Sie sich keine Sorgen zu machen. Wählen Sie einfach eine Version über 3.5.0 und Sie sind startklar.
Wenn Sie Parse 2.X verwenden, müssen Sie einige Änderungen am Code vornehmen.

Und warum GraphQL, wenn meine REST-API bereits funktioniert?

Auch diese Frage wird häufig gestellt, und ich glaube, dass es einige wesentliche Vorteile gibt, die für GraphQL gegenüber REST API sprechen.

Kurzfristig gesehen, wenn Sie Ihre Anwendung bereits mit REST API geschrieben haben und diese alle Ihre Bedürfnisse erfüllt, gibt es keinen Grund, zu GraphQL zu migrieren und den Code neu zu schreiben, nur weil es dafür Gründe gibt.

Andererseits, wenn Sie jetzt anfangen oder eine sich entwickelnde Anwendung vorhersehen, die an Komplexität zunehmen wird, und für eine vereinfachte zukünftige Wartung bereit sein wollen, kann GraphQL sich wirklich lohnen und Ihnen eine Menge Wert bringen.

Sagten Sie Wert?

Ja, das habe ich.

GraphQL hat einige entscheidende Vorteile, die die Code-Entwicklung und die Wartung im Laufe der Zeit vereinfachen und Ihnen sogar helfen können, bei der Datenübertragung zu sparen! Ja, genau! Sie haben richtig gelesen.

Lassen Sie uns Punkt für Punkt gehen:

• Vereinfachung der Code-Entwicklung

  Ganz am Anfang, wenn Sie mit GraphQL anfangen, müssen Sie vielleicht ein bisschen mehr Code produzieren. Lassen Sie sich davon nicht abschrecken.
  Mit GraphQL werden Ihre Abfragen einfacher zu schreiben sein, besonders wenn Sie unsere GraphQL-Konsole verwenden. Wenn Sie die Schemata verwenden, die Parse automatisch erstellt, und sowohl generische als auch spezifische Methoden für Abfragen und Mutationen für alle Ihre Klassen veröffentlichen, werden Sie viel Zeit sparen. Und ich meine wirklich eine Menge.
  Dokumentation? Kein Problem. Auch dafür haben wir gesorgt. Und sie wird auch automatisch generiert.
  Außerdem können sich Ihre Entwickler mit GraphQL auf die von Parse generierten Schemata verlassen, so dass sie bereits im Voraus wissen, welche Methoden ihnen zur Verfügung stehen, welche Parameter für jede Methode erforderlich sind und welche Rückgabewerte (Outputs) verfügbar sind. Sie müssen nicht mehr raten oder die anderen fragen, was diese Methode tut, welche Parameter erforderlich sind oder was sie zurückgibt. Es ist alles für Sie da.

• Vereinfachen Sie die Wartung

  Die Wartung mit GraphQL ist sehr, sehr einfach. Da die Aufrufe der API im Wesentlichen gleich sind, ist es genauso einfach, nur die Abfrage oder Mutation zu ändern, die Sie übergeben, wie die Abfrage oder Mutation zu ändern, um diese zu empfangen oder zu liefern.
  Sie müssen nicht viele Aufrufe, Blöcke oder Versprechen ändern. Ändern Sie die Abfrage oder Mutation: FERTIG!

• Sparen Sie bei der Datenübertragung

  Nach einiger Zeit der Arbeit mit Back4app ist es üblich, dass ich Kunden helfe, ihren Code zu optimieren, um schnellere Antworten zu erhalten. Und von allen Problemen, die ich in den Codes der Kunden finde, ist die große Mehrheit darauf zurückzuführen, dass Daten abgerufen werden, die die Anwendung in diesem Moment nicht braucht.
  Ein sehr häufiger Fehler beim Umgang mit der REST-API oder sogar den Parse-Frameworks besteht darin, die vollständigen Informationen für ein Objekt abzurufen und dann nur einen Teil dieser Informationen zu verwenden. Zum Beispiel:
  Sie haben eine Klasse namens Person mit einigen Eigenschaften: Name, Telefon, Adresse, Sozialversicherungsnummer, E-Mail und noch einige andere.
  In der Regel versuchen Benutzer, die die REST-API oder die Parse-Rahmenprogramme verwenden, das gesamte Objekt “Person” abzufragen, wobei sie alle Eigenschaften abrufen und dann nur eine oder zwei davon verwenden.
  Da bei GraphQL genau die Informationen angegeben werden müssen, die abgerufen werden sollen, hat der Entwickler keine Chance, unnötige Informationen abzurufen, was zu viel kleineren Nutzdaten führt, was sich in schnelleren Antworten, geringerem Verbrauch von Datenplänen und insgesamt weniger ausgehendem Datenverkehr niederschlägt. Ist das nicht großartig?

Probieren Sie es aus

Der beste Weg, um die Vorteile von GraphQL für Ihren Entwicklungsprozess zu erkennen, ist, es auszuprobieren.
Hier sind ein paar Szenarien, mit denen Sie spielen und sehen können, wie es sich verhält:

• Versuchen Sie, eine GraphQL-Abfrage zu erstellen und nicht genau anzugeben, was Sie abrufen wollen.

  Sie werden dazu nicht in der Lage sein. Sie werden zwangsläufig aufgefordert, das Gewünschte anzugeben, und nur das wird abgefragt. Sonst nichts.
  Wenn Sie oder Ihre Entwickler dies vergessen, wird GraphQL sie nicht davonkommen lassen.

Ich vermisse, was ich abrufe

Da haben Sie’s!

• Versuchen Sie, ein Objekt mit einer Query zu ändern

  Fehlanzeige. Sie wollen etwas ändern? Verwenden Sie die richtige Methode: Mutation.
  Wenn Sie oder Ihre Entwickler die falsche Methode verwenden, lässt GraphQL sie nicht fortfahren.

Eine Abfrage zum Ändern von Daten? Nein, nein, nein!

Mutation hat Sie im Griff!

• Mehrere Objekte, mehrere Abfragen? Fehlanzeige! EINE Abfrage!

  GraphQL macht es wirklich einfach, Informationen über mehrere Objekte mit nur einer Abfrage abzurufen, was die Entwicklung vereinfacht und den Code weniger fehleranfällig macht.
  Stellen Sie sich vor, Sie haben eine Personenklasse und eine Person kann einen Hund haben, der zur Hundeklasse gehört. Sie müssen Informationen aus diesen beiden Klassen abrufen: den Namen und das Alter der Person sowie den Namen und die Rasse des Hundes. Ein Kinderspiel:

Versionierung? Wozu?

Versionierung von Code ist soooo 2018’s.
Füge neue Felder zu deiner Abfrage hinzu. Alte Aufrufe funktionieren noch:

Das funktioniert

Dies funktioniert auch. Aufrufe an den alten Typ funktionieren weiterhin.

Veraltete Felder sagten Sie? Auch hier ein Kinderspiel:

Schlussfolgerung

GraphQL ist nicht dazu da, irgendetwas zu vernichten. Es ist dazu da, eine neue Art und Weise zu schaffen, alte Dinge zu tun. Besser, schneller, wartungsfreundlicher und weniger anfällig für Fehler.

Es wird Sie auf dem richtigen Weg halten, wenn Sie abrutschen. Es wird Ihnen sagen, was Sie tun können und was nicht.

Zusammen mit Parse und den automatisch generierten Methoden (sowohl generisch als auch spezifisch) und der Dokumentation wird es Ihnen das Erlernen der Methode zum Kinderspiel machen.

Wenn Sie es noch nie ausprobiert haben, sollten Sie es tun. Alle coolen Kids tun es.

Wenn Sie mehr über GraphQL vs. REST wissen wollen, lesen Sie unseren Medium-Beitrag.