Wenn Sie eine API erstellen müssen, werden Sie wahrscheinlich an Folgendes denken RUHE, das de facto Standard für die API-Erstellung. Dies ändert sich jedoch mit der Zunahme von GraphQL Popularität.
Nicht jeder versteht vollständig, worum es bei GraphQL geht oder warum es zum Nachfolger von REST erklärt wird. Genau das werde ich in diesem Artikel klären. Hier werde ich angeben Die Hauptfunktionen von GraphQL und Vorteile gegenüber REST, wobei einige Punkte hervorgehoben werden, in denen sich beide unterscheiden.
Ziel ist es, allen, die GraphQL noch nicht kennen, eine kurze Erklärung zu geben, zu klären, was es besser kann als REST für diejenigen, die dieser Technologie immer noch skeptisch gegenüberstehen, und in welchen Fällen wir GraphQL oder REST verwenden sollten.
GraphQL ist ein Abfragesprache für APIs das ermöglicht das deklarative Abrufen von Daten, um dem Client die Möglichkeit zu geben, genau die Daten anzugeben, die von der API benötigt werden. Es macht es einfacher, APIs im Laufe der Zeit weiterzuentwickeln.
Jetzt, da wir wissen, was GraphQL ist, möchte ich klarstellen, was es nicht ist, da ich das Gefühl habe, dass es immer noch einige Verwirrung darüber gibt.
Erstens es hat nichts mit Datenbanken zu tun. Es ist keine Alternative zu SQL oder einem brandneuen ORM.
Zweitens es ist kein REST-Ersatz, aber eine Alternative. Sie müssen sich nicht zwischen dem einen und dem anderen entscheiden, sie können problemlos im selben Projekt koexistieren.
Nicht zuletzt ist GraphQL nicht kompliziert oder beängstigend. Es ist ziemlich einfach, seinen deklarativen Charakter zu verstehen und genau zu verstehen, wie es möglich ist, das Beste daraus zu machen.
GraphQL wurde 2012 intern von Facebook entwickelt, bevor es 2015 als Open Source veröffentlicht wurde. Die stabile Version wurde erst im Juni 2018 veröffentlicht. Am 7. November 2018 wurde das GraphQL-Projekt von Facebook in die neu gegründete GraphQL Foundation verschoben, die von der gemeinnützigen Linux Foundation betrieben wird.
Lee Byron, der Schöpfer von GraphQL, möchte GraphQL auf allen Webplattformen allgegenwärtig machen.
GraphQL wird verwendet von Teams in allen Größen, in vielen verschiedenen Umgebungen und Sprachen. Die wichtigsten Unternehmen, die GraphQL verwenden, sind Facebook, Github, Pinterest und Shopify.
Bevor ich zum Vergleich mit REST übergehe, werde ich eine einfache GraphQL-Abfrage durchführen, mit der wir einen Benutzer sowie seinen Namen und sein Alter abrufen können:
Und die JSON-Antwort, die wir daraus erhalten werden:
Wie ich bereits sagte, macht es der deklarative Charakter von GraphQL unglaublich einfach zu verstehen, was zu jeder Zeit vor sich geht, da wir im Grunde schreiben JSON Objekte ohne die Werte.
REST wurde von Roy Fielding definiert, einem Informatiker, der die REST-Prinzipien in seinem Doktorarbeit im Jahr 2000.
REST (Representational State Transfer) ist ein Software-Architekturstil das definiert eine Reihe von Einschränkungen, die jeden Webservice zu einer echten RESTful-API machen. Die REST-Einschränkungen sind:
Die Client-Server-Architektur bedeutet, dass die Belange der Benutzeroberfläche von den Bedenken hinsichtlich der Datenspeicherung getrennt werden sollten, um die Portabilität der Benutzeroberflächen auf mehreren Plattformen zu verbessern.
Ein statusloser Server speichert keine Informationen über den Benutzer, der die API verwendet. Dies bedeutet, dass der Server sich nicht daran erinnert, ob der Benutzer seine erste Anfrage sendet oder nicht.
REST-API-Antworten müssen sich selbst als zwischenspeicherbar oder nicht zwischenspeicherbar definieren, um zu verhindern, dass Kunden unangemessene Daten bereitstellen, die für zukünftige Anfragen verwendet werden können.
Ein geschichtetes System bedeutet, dass, wenn Proxy oder Load Balancer wird zwischen Client und Server platziert, die Verbindungen zwischen ihnen sollten nicht beeinträchtigt werden, und der Client wusste nicht, ob er mit dem Endserver verbunden ist oder nicht.
Eine einheitliche Oberfläche legt nahe, dass es sich um eine einheitliche Art der Interaktion mit einem bestimmten Server handeln sollte, unabhängig vom Geräte- oder Anwendungstyp (Website, mobile App). Die wichtigste Richtlinie ist, dass jede Ressource auf Anfrage identifiziert werden muss.
Unter Berücksichtigung aller REST-Einschränkungen zeigt das folgende Bild den REST-Architekturstil:
Es gibt zwei Hauptgründe, warum Unternehmen wie Facebook, Netflix und Coursera begann mit der Entwicklung von Alternativen zu REST:
1. In den frühen 2010er Jahren gab es einen Boom bei der mobilen Nutzung, was zu einigen Problemen mit Geräten mit geringem Stromverbrauch und schlampigen Netzwerken führte. REST ist nicht optimal, um diese Probleme zu lösen;
2. Mit der zunehmenden Nutzung von Mobilgeräten stieg auch die Anzahl der verschiedenen Frontend-Frameworks und -Plattformen, auf denen Client-Anwendungen ausgeführt werden. Angesichts der Inflexibilität von REST war es schwieriger, eine einzige API zu entwickeln, die den Anforderungen jedes Kunden gerecht wurde.
Wenn wir noch weiter gehen, stellen wir fest, dass der Hauptgrund für die Identifizierung einer alternativen Lösung darin bestand, dass die meisten Daten, die in modernen Web- und Mobilanwendungen verwendet werden, eine grafische Form haben. Nachrichten enthalten beispielsweise Kommentare, und diese Kommentare können Funktionen wie „Gefällt mir“ -Angaben oder Spam-Markierungen enthalten, die von Benutzern erstellt oder gemeldet werden. Dieses Beispiel beschreibt, wie ein Diagramm aussieht.
Folglich Facebook begann mit der Entwicklung von GraphQL. Gleichzeitig arbeiteten Netflix und Coursera auch selbst an Alternativen. Nachdem Facebook GraphQL als Open-Source-Lösung bereitgestellt hatte, stellte Coursera seine Bemühungen ein und übernahm die neue Technologie. Netflix entwickelte jedoch weiterhin seine eigene REST-Alternative und später als Open-Source-Lösung Falcor.
In den nächsten Abschnitten werde ich erklären, warum GraphQL mehr Flexibilität bietet als REST, aber schauen wir uns zunächst die Architektur an.
Ist GraphQL besser als REST? GraphQL bietet eine Abfragesprache, mit der Kunden nur die Daten anfordern können, die sie benötigen, und Aktualisierungen in Echtzeit ermöglicht. REST basiert auf starren Endpunkten und Datenstrukturen. Ob GraphQL „besser“ ist, hängt von den spezifischen Anforderungen und der Flexibilität ab, die in einem API-gesteuerten Projekt erforderlich sind.
In diesem Abschnitt werde ich Punkt für Punkt ein praktisches Beispiel durchgehen, Vergleich von REST mit GraphQL um die Flexibilität der Abfragesprache von Facebook zu demonstrieren.
Stellen Sie sich vor, Sie haben eine Blog, und Sie möchten, dass auf der Titelseite die neuesten Beiträge angezeigt werden. Um dies zu erreichen, müssen Sie die Beiträge abrufen, also werden Sie wahrscheinlich so etwas tun:
GET /api/posts
Aber was ist, wenn Sie den Autor auch sehen möchten? Sie haben drei Möglichkeiten, dies zu erreichen:
Jeder dieser Ansätze wird ein eigenes Problem mit sich bringen. Schauen wir uns sie also nacheinander an, um zu sehen wie GraphQL in der Lage ist, die folgenden Probleme zu lösen.
Beim ersten Ansatz — dem Abrufen der Autoren von einer anderen Ressource — erhalten Sie am Ende zwei Serveranfragen statt einer, und wenn Sie weiter skalieren, erhalten Sie möglicherweise noch mehr Anfragen an verschiedene Endpunkte, um alle benötigten Daten abzurufen.
Mit GraphQL würde das nicht passieren. Du hättest nur eine Anfrage, und du müsstest nicht mehrere Roundtrips zum Server machen, wie unten gezeigt:
Wenn Sie sich den zweiten Ansatz ansehen — die Ressource so ändern, dass auch der Autor zurückgegeben wird — können Sie sehen, dass das Problem damit ziemlich gut gelöst wurde. Das Ändern einer Ressource kann jedoch an anderer Stelle in Ihrer Anwendung sekundäre Auswirkungen haben. Genauer gesagt übermäßiges Abrufen.
Gehen wir zurück zu Ihrem Blog, aber dieses Mal haben Sie auch eine Seitenleiste, in der die wichtigsten monatlichen Beiträge mit ihren Titeln, Untertiteln und Datum angezeigt werden, die die Ressource verwenden /api/posts. Da Sie die Ressource geändert haben, wird jetzt auch der Autor damit angezeigt. Wir benötigen es jedoch nicht für die Seitenleiste.
Dies mag zwar nicht nach einem Problem aussehen, aber für Benutzer mit begrenzten Datentarifen ist es nicht ideal, wenn eine Website nutzlose Daten abruft. Seit GraphQL ermöglicht es dem Client, nur die benötigten Daten abzurufen, dieses Problem würde nicht existieren:
Schauen wir uns abschließend den letzten Ansatz an — das Erstellen einer Ressource, die die Beiträge zusammen mit dem Autor zurückgibt —, da es ein übliches Muster ist, die Endpunkte entsprechend den Ansichten in Ihrem Projekt zu strukturieren.
Dies kann zwar Probleme wie das oben beschriebene lösen, verlangsamt aber auch die Frontend-Entwicklung, da jede spezifische Ansicht ihren spezifischen Endpunkt benötigt. Wenn eine Ansicht zu irgendeinem Zeitpunkt neue Daten benötigt, muss die Entwicklung verlangsamt werden, bis der Endpunkt aktualisiert ist.
Nochmals, da GraphQL dem Client die Möglichkeit gibt, nur die benötigten Daten abrufen, nichts verlangsamt sich, da es sehr einfach ist, einfach ein neues Feld hinzuzufügen.
Du würdest davon bekommen:
Dazu:
Lassen Sie uns einfach eine kurze Zusammenfassung der Unterschiede zwischen REST und GraphQL machen:
Wie bereits erwähnt, GraphQL ersetzt REST nicht. Trotz ihrer Unterschiede haben GraphQL und REST auch Ähnlichkeiten:
BEKOMMENAnfrage mit einer URL und Rückgabe der Anfrage in JSON-Daten.Mutationund die Abfrage types () ist identisch mit der Liste der Endpunkte in einem REST-API.Heutzutage strebt fast jedes Unternehmen danach, mobile plattformübergreifende Anwendungen zu entwickeln, da die Kundeninteraktion mit dem Produkt erheblich zunimmt, wenn sie über ihre Telefone darauf zugreifen können. Wenn Sie eine mobile App verwenden, erwarten Sie, dass sie schnell reagiert und eine geringe Latenz aufweist.
Mit GraphQL können Sie diese Ziele auf sehr einfache Weise erreichen. Es hilft dem Client, die Datenmenge abzurufen, die zum Rendern einer bestimmten Ansicht benötigt wird.
Bis jetzt kann ich mir vorstellen, dass wir die gleiche Meinung teilen, dass GraphQL großartig ist, aber das ist nicht ganz richtig. Es fehlen noch einige Elemente, um es perfekt zu machen. Wenn Sie einen der nächsten Punkte in Ihrem Projekt haben möchten, sollten Sie die Verwendung von REST in Betracht ziehen.
Heutzutage bietet jeder Browser eine Implementierung eines HTTP-Cache, um das erneute Abrufen von Ressourcen einfach zu vermeiden und um festzustellen, ob zwei Ressourcen identisch sind.
Bei Verwendung von GraphQL gibt es keine Möglichkeit, einen global eindeutigen Bezeichner für ein bestimmtes Objekt zu erhalten, da wir für alle Anfragen dieselbe URL verwenden. Um einen Cache zu haben auf GraphQL musst du deinen eigenen Cache einrichten.
Wenn Sie REST verwenden, können Sie ein Überwachungssystem erstellen, das auf API-Antworten basiert. Bei GraphQL hast du das nicht, weil es immer zurückkehrt 200 OK Statusantwort. Ein typischer GraphQL-Fehler sieht so aus:
Wenn Sie sich diese Antwort ansehen, können Sie sehen, dass es sehr schwierig ist, damit umzugehen und verschiedene Fehlerszenarien zu überwachen.
Wie Sie jetzt wissen, können Sie mit GraphQL genau das abfragen, was Sie wollen, wann immer Sie wollen, aber wir sollten uns bewusst sein, dass dies zu komplexen Auswirkungen auf die Sicherheit führt. Wenn ein böswilliger Akteur versucht, eine teure verschachtelte Abfrage einzureichen, um Ihren Server oder Ihre Datenbank zu überlasten, und Ihr Server nicht über die richtigen Schutzmaßnahmen verfügt, sind Sie anfällig für DDoS (Denial-of-Service-Angriff) Angriffe.
Nachdem wir nun wissen, wie es im Vergleich zu REST abschneidet, wollen wir über einige der Funktionen sprechen, die nur GraphQL bietet.
GraphQL verwendet sein eigenes Typsystem, um das Schema einer API zu definieren. Die Syntax heißt Schemadefinitionssprache (SDL). Das Schema dient als Vertrag zwischen dem Server und dem Client, um zu definieren, wie ein Client auf die Daten zugreifen kann.
Sobald das Schema definiert ist, werden das Frontend und Backend Teams können unabhängig voneinander arbeiten, da das Frontend einfach mit Scheindaten getestet werden kann. Das Frontend kann auch nützliche Informationen aus dem Schema abrufen, wie z. B. seine Typen, Abfragen und Mutationen mithilfe von Grafik QL oder Introspektion. Das Das Schema von GraphQL bietet auch Typsicherheit, was für die Frontend- und Backend-Entwicklung von Vorteil ist, da Tippfehler frühzeitig erkannt werden.
Ein Schemabeispiel:
GraphQL IDE ist eine der nützlichsten Funktionen der GraphQL-Entwicklung. Es nutzt seinen selbstdokumentierenden Charakter, um die Entwicklung zum Kinderspiel zu machen.
Mit GraphiQL oder GraphQL-Spielplatz, Sie können einfach Ihr Schema überprüfen und sogar Abfragen und Mutationen ausführen, um Ihre API zu testen.
GraphQL bietet eine reibungslose und schnelle Entwicklungsumgebung mit seinem deklarativen und flexiblen Charakter, der viele Verbesserungen gegenüber REST bietet.
Es hat bereits eine große Community und ein lebendiges Ökosystem und wurde bereits implementiert in mehrere beliebte Sprachen, wie Javascript, Geh und Java.
Dieser Beitrag hat zwar nur die Zehen in den Ozean getaucht, aber GraphQL ist Webseite hat eine Fülle von Informationen und ist ein großartiger Ort, um GraphQL zu lernen und zu verwenden.
Wenn du darauf abzielst Entwickeln Sie eine API, die in einer mobilen Anwendung verwendet werden kann das hättest du tun sollen GraphQL als erste Option weil die Bandbreitennutzung wichtig ist. Wenn dein Anwendung erfordert eine robuste API, mit Caching und einem Monitoringsystem du solltest mit REST gehen.
Trotz alledem handelt es sich nicht um eine perfekte Technologie, und im Vergleich zu REST weist sie immer noch einige Nachteile auf. Aber wenn man bedenkt, wie jung es ist, sieht die Zukunft für GraphQL unglaublich rosig aus.
Webentwickler, der häufig Null statt Null eingibt. Ich liebe es, den funktionalen Stil von Javascript zu erkunden.
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
