Hat GraphQL in der HTTP / 2-Ära an Relevanz verloren?

Phil Sturgeon hat kürzlich einen Tweet gepostet, der GraphQL-Fans sehr getroffen hat. In diesem Tweet wurde darüber gesprochen, wie GraphQL per Definition eine Technologie ist, die dem Wesen von HTTP / 2 widerspricht. Die Tatsache, dass der HTTP / 3-Standard bereits veröffentlicht wurde und dass der Autor des Tweets diejenigen nicht wirklich versteht, die sich bei der Auswahl von GraphQL auf den Weg der Inkompatibilität begeben. Schauen Sie sich dieses Material an, um die Gründe für Phils Einstellung zu GraphQL besser zu verstehen.



Etwa zur gleichen Zeit wurde eine Ankündigung über das Vulcain- Projekt gemacht. Diese Nachricht enthielt die Worte: "TL / DR: GraphQL, das Sie nicht mehr benötigen!". Und schließlich wurde ein großartiger Artikel von Mark Nottingham über die leistungsstarken Funktionen von HTTP / 2 und die Bedeutung dieser Funktionen für diejenigen veröffentlicht, die die API entwerfen. Darrel Miller hat einen Link zu diesem Artikel mit seinen Abonnenten geteilt.

Was geschah, ließ mich über GraphQL und HTTP / 2 nachdenken. Wenn alles mit HTTP / 2 (und HTTP / 3) funktioniert, haben wir dann keinen Grund, GraphQL zu verwenden? Ich würde es heute gerne herausfinden.

HTTP / 2-Innovationen

Lassen Sie uns zunächst herausfinden, was die HTTP / 2-Technologie in den Augen der Entwickler auf den Wert von GraphQL auswirken kann. HTTP / 2 hat viel zu bieten. Dies ist beispielsweise ein neues Binärformat und eine verbesserte Header-Komprimierung. In unserem Fall spielt die Hauptrolle jedoch die Verarbeitung der Übermittlung von Anforderungen und Antworten bei Verwendung von HTTP / 2.

Das Öffnen einer TCP-Verbindung ist eine kostspielige Operation. Clients, die HTTP / 1 verwenden, führen es normalerweise nicht zu oft aus. Aus diesem Grund haben Entwickler aufgrund der großen zusätzlichen Belastung des Systems häufig versucht, die Anzahl der Anforderungen zu begrenzen, indem sie auf eine Vielzahl von Technologien zurückgegriffen haben. Dies können beispielsweise Stapelabfragen ausführen, Abfragesprachen verwenden, CSS / JS-Code in den Seitencode einbetten, Sprite-Blätter anstelle einzelner Bilder verwenden usw. In HTTP / 1.1. Es wurde versucht, einige dieser Probleme mithilfe von dauerhaften Verbindungen und Pipeline- Datenverarbeitung zu lösen. Diese beiden Technologien ermöglichten es Browsern, innerhalb derselben Verbindung mehrere Anfragen zu senden und Antworten darauf zu erhalten. Der Nachteil eines solchen Datenaustauschschemas bestand darin, dass es dem Problem unterworfen war, den Beginn der Warteschlange zu blockieren ( Head-of-Line-Blockierung ). Dieses Problem drückt sich darin aus, dass eine langsame Anforderung die Verarbeitung aller darauf folgenden Anforderungen verlangsamen kann. Die Experten, die an HTTP / 2 gearbeitet haben, schlugen verschiedene Möglichkeiten zur Lösung dieses Problems vor. Zusammen mit dem neuen Binärprotokoll führt HTTP / 2 eine neue Datenlieferungsstrategie ein. Während der Interaktion von Systemen, die das HTTP / 2-Protokoll verwenden, wird eine einzelne Verbindung geöffnet, in deren Rahmen das Multiplexen von Anforderungen und Antworten unter Verwendung einer neuen Binärebene durchgeführt wird, die für die Arbeit mit Frames ausgelegt ist, wenn jeder Frame Teil eines Streams ist. Mithilfe dieses Mechanismus können Clients und Server Anforderungs- und Antwortflüsse basierend auf den Informationen in Frames neu erstellen. Dadurch kann HTTP / 2 die Verarbeitung vieler Anforderungen, die innerhalb einer einzelnen Verbindung ausgeführt werden, sehr effektiv unterstützen.

Das ist aber noch nicht alles. HTTP / 2 hat ein neues Konzept namens Server Push. Wenn Sie nicht auf Details eingehen, können wir sagen, dass diese Technologie es Servern ermöglicht, Daten im Voraus an Clients zu senden, bevor Clients diese Daten anfordern. Die auffälligsten Beispiele für dieses Verhalten sind das Senden von Stylesheets und JavaScript-Ressourcen an Clients im Voraus. Beim Generieren einer Antwort auf die HTTP-Anforderung kann der Server feststellen, dass zum Rendern der HTML-Seite eine CSS-Datei erforderlich ist, und im Voraus feststellen, dass der Client ihn in Kürze für diese Datei kontaktieren wird. Auf diese Weise kann der Server die angegebene Datei an den Client senden, noch bevor der Client sie anfordert. So funktioniert das oben erwähnte Vulcain- Projekt, bei dem mithilfe dieser Technologie das effiziente Laden verwandter Ressourcen organisiert wird.

Also, während alles klar ist. Aber was hat das alles mit GraphQL zu tun?

GraphQL: Eine Abfrage, die alle Probleme löst

Die GraphQL-Technologie ist teilweise auf ihre Attraktivität zurückzuführen, da sie Entwicklern hilft, die für HTTP / 1-Verbindungen typischen Nachteile zu bewältigen.

Aus diesem Grund können Kunden mit GraphQL in einer Sitzung mit dem Server kommunizieren und Anforderungen erfüllen, um fast alles zu empfangen. Dies kann mit der Hypermedia-API verglichen werden, bei deren Verwendung Sie normalerweise viele Netzwerkanforderungen ausführen müssen (manchmal kann Caching jedoch die Situation verbessern).


Die Fähigkeit, mehrere Ressourcen innerhalb einer einzigen Abfrage zu empfangen, ist eine der Stärken von GraphQL , auf die die Entwickler dieser Technologie die Aufmerksamkeit ihrer potenziellen Benutzer lenken.

Viele von denen, die sagen, dass mit dem Aufkommen von HTTP / 2 niemand GraphQL-Technologie benötigt, meinen diese Möglichkeit. Die Verwendung von Batch-APIs, Abfragesprachen (wie GraphQL), die Optimierung von Beziehungen und sogar die Erstellung aggregierter Endpunkte sind jetzt weniger attraktiv als zuvor. Die Sache ist, dass die "Kosten" für die Durchführung von Abfragen gering werden. Und das ist wahr. Aber verwenden wir GraphQL nur deshalb? Ich glaube nicht.

Vielleicht ist die Tatsache, dass jetzt noch die Anfänge von HTTP / 2-Clients und einigen Serveranwendungen sind?

Ich denke nicht, dass die im Titel dieses Abschnitts gestellte Frage eine würdige Erklärung für die Tatsache darstellt, dass wir GraphQL immer noch weit verbreitet verwenden. Aber es ist erwähnenswert. Die Verwendung von HTTP / 2 auf Anwendungsebene in einigen Ökosystemen ist eine Herausforderung, die noch lange nicht gelöst ist. Suchen Sie beispielsweise nach den Wörtern "Rack / Rails über HTTP / 2." Es wird interessant sein. Die Sache ist, dass viele Serverteile von Anwendungen unter Verwendung des Anforderungs- / Antwortmusters erstellt werden. Daher ist der Wechsel zum Konzept der HTTP / 2-Streams nicht so einfach. Besonders - bei einigen Frameworks. Dies ist jedoch eine unwürdige Ausrede. Viele Ökosysteme unterstützen dieses Interaktionsschema zwischen Clients und Servern perfekt, und theoretisch sollten wir uns weiterhin bemühen, diese Interaktion zu verbessern. (Die meisten Proxys unterstützen dies ebenfalls, aber es ist nicht einfach, auf Initiative des Servers Daten wie das Senden von Daten an einen Client zu organisieren, wenn die Serveranwendung in der Vergangenheit mithilfe eines Anforderungs- / Antwortmusters hängen geblieben ist.)

GraphQL ist mehr als die Verkürzung der Zeit zum Empfangen und Senden von Daten oder die Optimierung der übertragenen Informationsmenge

Obwohl die Verkürzung der Zeit zum Empfangen und Senden von Daten und die Optimierung der Menge der übertragenen Informationen die Stärken von GraphQL sind, von denen wir ständig hören, bietet uns diese Technologie viel mehr.

Die Stärke der GraphQL-Technologie liegt in der Fokussierung auf Client-Systeme. Der Client ist die Umgebung, in der GraphQL viele Kompromisse eingeht. In den letzten Jahren hat dies viele gestört. Daniel Jacobson hat vor 5-7 Jahren viele gute Artikel über einige dieser Probleme geschrieben. Hier und da - ein paar seiner Publikationen. In einem von ihnen sagt er: „Unsere REST-APIs sind zwar in der Lage, allgemeine Anforderungen zu verarbeiten, sind jedoch für keine dieser Anforderungen optimiert.“

Bitte beachten Sie, dass diese Idee nicht nur für die REST-Technologie gilt. Clientanwendungen müssen häufig mehr Serveranforderungen ausführen, als ihre Entwickler möchten. Diese Anwendungen müssen sich mit dem Empfang unnötiger Daten von Servern befassen. Hier geht es mehr darum, APIs zu entwerfen, die sich gut erstellen lassen, damit sie viele verschiedene Verwendungszwecke unterstützen. Die übliche Methode zur Lösung dieses Problems besteht darin, die Client-Logik so nah wie möglich an der Server-Logik zu halten. Ein Beispiel für diesen Ansatz sind die in diesem Artikel von 2012 erwähnten Netflix-Clientadapter. Seitdem haben einige Netflix-Teams sogar auf GraphQL umgestellt. Das BFF- Muster zielt auch darauf ab, solche Probleme zu lösen.

Die GraphQL-Technologie ändert das Konzept der Grenze zwischen Client und Server und hilft uns dabei, Serversysteme zu erstellen, die Informationen darüber enthalten können, wie sie von Clients verwendet werden. Dies zeigt sich ganz deutlich bei der Verwendung der Technologie ständiger Anforderungen, da es sich hier im Wesentlichen um Serverressourcen handelt, die auf Initiative des Clients generiert werden.

Denken Sie beim Nachdenken über die Relevanz von GraphQL in der HTTP / 2-Welt daran, dass es sich um Serverabstraktion handelt. Die Unterstützung einer Vielzahl von Anwendungsfällen für Serverdaten kann zu Problemen bei herkömmlichen endpunktbasierten APIs führen. Mit GraphQL können sich diejenigen, die die API unterstützen, darauf konzentrieren, Benutzern dieser APIs eine breite Palette von Funktionen zur Verfügung zu stellen. Gleichzeitig machen sich die Eigentümer der API möglicherweise keine Sorgen über die zunehmende Belastung bestehender Clients und darüber, dass die Unterstützung für die API aufgrund der Notwendigkeit, viele verschiedene Ressourcen zu unterstützen, viel komplizierter wird. (Die Unterstützung vieler verschiedener Ressourcen hat ihre Nachteile. Daher erschweren solche Schemata die Leistungsoptimierung. Solche Ressourcen werden nicht immer gut zwischengespeichert. APIs, die stark optimiert werden können, haben dieselben Probleme.)

Client-Systeme und GraphQL-Entwicklung

In diesem Artikel spreche ich hauptsächlich über Server, aber es ist wichtig zu bedenken, dass Client-Entwickler die GraphQL-Technologie sehr mögen. Wenn Sie GraphQL-Fragmente mit dem Komponentenansatz moderner Front-End-Frameworks kombinieren, erhalten Sie eine völlig erstaunliche Abstraktion. Und wenn wir hier ständig Abfragen hinzufügen, können wir sagen, dass GraphQL Entwicklern von Client-Systemen das Leben erleichtert.

GraphQL ist ein ganzheitliches System mit bemerkenswerten Funktionen

GraphQL verfügt nicht über völlig einzigartige Funktionen. Es gibt Alternativen zu diesem System. Typisiertes Schema? Das gleiche gilt für OpenAPI! Server-Abstraktionen, die verschiedene Client-Anwendungsfälle unterstützen? Dies kann auf viele Arten implementiert werden. Selbstbeobachtung? Mithilfe von Hypermedia können Clients Aktionen erkennen und mit der Stammentität arbeiten. Ein köstliches GraphiQL-Tool? Ich bin sicher, dass etwas Ähnliches für OpenAPI erstellt wurde. Die Möglichkeiten von GraphQL können immer mit anderen Technologien neu erstellt werden. GraphQL ist jedoch ein ganzheitliches System. Dies ist es, was ein so großes Publikum von Entwicklern für GraphQL anzieht, die dieses System gerne nutzen. Ich vermute, dass dies einer der Gründe für die schnelle Verbreitung und Entwicklung von GraphQL ist. Da der Aufbau der GraphQL-API gut dokumentiert ist, sind GraphQL-Bibliotheken, die für verschiedene Sprachen entwickelt wurden, normalerweise von hoher Qualität und Beliebtheit.

Die Vernetzung ist immer noch ein begrenzender Faktor (oder wird es immer so sein?)

Hier ist ein weiterer Gedanke, auf den ich näher eingehen möchte. Es besteht das Gefühl, dass das Netzwerk bei der Arbeit mit der API immer die Rolle eines begrenzenden Faktors spielt. Es spielt keine Rolle, wie schnell die Netzwerkanforderungen sind. Aus diesem Grund entwerfen wir Web-APIs nicht auf die gleiche Weise wie normale Objekte, die in verschiedenen Programmiersprachen verwendet werden. Hier sprechen wir zum Beispiel darüber, warum Schnittstellen mit einem hohen Detaillierungsgrad nicht sehr gut geeignet sind, um Systeme zu erstellen, die für die Remote-Arbeit mit ihnen ausgelegt sind.

Während HTTP / 2 definitiv die Ausführung von Anforderungen mit hoher Granularität fördert, denke ich, dass hier einige Kompromisse gemacht werden müssen.

Kann HTTP / 2 GraphQL helfen?

GraphQL bietet dem Entwickler viele wichtige und nützliche Tools, aber HTTP / 2 ist auch eine großartige Technologie. Lassen Sie uns in die Zukunft schauen und über die Vorteile nachdenken, die GraphQL-Systeme von der Verwendung von HTTP / 2 profitieren können. Zum Beispiel könnte es so aussehen:

query {   viewer {     name     posts(first: 100) @stream {       title     }   } } 

Es stellt sich heraus, dass wir die serverseitige Abstraktion von GraphQL, der deklarativen Abfragesprache dieser Technologie, gut nutzen und gleichzeitig die Funktionen von HTTP / 2-Streams nutzen können. Ich denke, dass hier Web-Sockets verwendet werden. Ich muss das noch herausfinden, aber ich bin sicher, dass viele bereits GraphQL-Anweisungen wie @defer , @stream und @live .

Zusammenfassung

HTTP / 2 ist eine großartige Technologie (und die hier aufgeführten Beispiele sind nur eine Art Wunder). GraphQL kann nur als eine Technologie wahrgenommen werden, die die Anzahl der Client-Server-Kommunikationssitzungen reduziert oder zur Optimierung des übertragenen Datenvolumens beiträgt. Wenn ja, kann jeder, der GraphQL aus einer ähnlichen Perspektive betrachtet, APIs verwenden, die auf HTTP / 2-Funktionen basieren. Wenn Sie jedoch in GraphQL eine Kombination von Technologien sehen, die dem Entwickler viele nützliche Dinge bieten, wird klar, dass die Leistungsfähigkeit von GraphQL keineswegs darauf beschränkt ist, die Nutzung von Netzwerkressourcen zu verbessern und Datenverkehr zu sparen.

Liebe Leser! Wenn Sie die GraphQL-Technologie verwenden, teilen Sie uns bitte mit, was Ihnen am besten gefällt.