Phil Sturgeon a récemment publié un
tweet qui a beaucoup touché les fans de GraphQL. Ce tweet a expliqué comment GraphQL est, par définition, une technologie qui contredit l'essence de HTTP / 2. Le fait que la norme HTTP / 3 soit déjà sortie, et que l'auteur du tweet ne comprenne pas vraiment ceux qui, en choisissant GraphQL, vont dans le sens de l'incompatibilité. Afin de mieux comprendre les raisons de l'attitude de Phil envers GraphQL, jetez un œil à
ce matériel.
Vers la même époque, une annonce a été faite au sujet du projet
Vulcain . Ce message comprenait les mots: "TL / DR: GraphQL vous n'avez plus besoin!". Et enfin, un excellent
article de Mark Nottingham a été publié sur les puissantes fonctionnalités de HTTP / 2 et ce que ces fonctionnalités signifient pour ceux qui conçoivent l'API. Darrel Miller a
partagé un lien vers cet article avec ses abonnés.
Ce qui se passait m'a fait penser à GraphQL et HTTP / 2. Si tout commence à fonctionner avec HTTP / 2 (et HTTP / 3), cela signifie-t-il que nous n'avons aucune raison d'utiliser GraphQL? Je voudrais le savoir aujourd'hui.
Innovations HTTP / 2
Pour commencer, découvrons ce que la technologie HTTP / 2 peut affecter la valeur de GraphQL aux yeux des développeurs. HTTP / 2 a beaucoup à offrir. Il s'agit, par exemple, d'un nouveau format binaire et d'une compression d'en-tête améliorée. Mais dans notre cas, le rôle principal est joué par la façon dont la livraison des demandes et des réponses est traitée lors de l'utilisation de HTTP / 2.
L'ouverture d'une connexion TCP est une opération coûteuse. Les clients utilisant HTTP / 1 ont tendance à ne pas l'exécuter trop souvent. Pour cette raison, en raison de la charge supplémentaire importante sur le système, les développeurs ont souvent essayé de limiter le nombre de demandes en recourant à une variété de technologies. Cela, par exemple, exécuter des requêtes par lots, utiliser des langages de requête, incorporer du code CSS / JS dans le code de la page, utiliser des feuilles de sprites au lieu d'images individuelles, etc. Dans HTTP / 1.1. une tentative a été faite pour résoudre certains de ces problèmes en utilisant des connexions persistantes et un traitement des données en
pipeline . Ces deux technologies permettaient aux navigateurs d'envoyer, au sein d'une même connexion, plusieurs requêtes et d'y recevoir des réponses. L'inconvénient d'un tel système d'échange de données était qu'il était sujet au problème de blocage du début de la file d'attente (
blocage en tête de ligne ). Ce problème s'exprime par le fait qu'une seule requête lente peut ralentir le traitement de toutes les requêtes qui la suivent. Les experts qui ont travaillé sur HTTP / 2 ont suggéré différentes manières de résoudre ce problème. Avec le nouveau protocole binaire, HTTP / 2 introduit une nouvelle stratégie de livraison de données. Lors de l'interaction des systèmes utilisant le protocole HTTP / 2, une seule connexion est ouverte, dans le cadre de laquelle le multiplexage des requêtes et des réponses est effectué à l'aide d'un nouveau niveau binaire conçu pour fonctionner avec des trames, lorsque chaque trame fait partie d'un flux. À l'aide de ce mécanisme, les clients et les serveurs peuvent recréer des flux de demandes et de réponses en fonction des informations les concernant qui se trouvent dans les trames. Cela permet à HTTP / 2 de prendre en charge très
efficacement le traitement de nombreuses requêtes qui sont exécutées au sein d'une seule connexion.
Mais ce n'est pas tout. HTTP / 2 a un nouveau concept appelé Server Push. Si vous n'entrez pas dans les détails, nous pouvons dire que cette technologie permet aux serveurs d'envoyer des données aux clients à l'avance, avant de demander ces données. Les exemples les plus frappants de ce comportement sont l'envoi préalable de feuilles de style et de ressources JavaScript aux clients. Dans le processus de génération d'une réponse à la requête HTTP, le serveur peut découvrir qu'un fichier CSS est nécessaire pour rendre la page HTML et savoir à l'avance que le client le contactera bientôt pour ce fichier. Cela permet au serveur d'envoyer le fichier donné au client avant même que le client ne le demande. C'est ainsi que fonctionne le projet
Vulcain susmentionné, en utilisant cette technologie pour organiser le chargement efficace des ressources associées.
Donc, alors que tout est clair. Mais qu'est-ce que tout cela a à voir avec GraphQL?
GraphQL: une requête qui résout tous les problèmes
La technologie GraphQL est en partie due à son attractivité en ce qu'elle aide les développeurs à faire face aux inconvénients typiques des connexions HTTP / 1.
C'est pourquoi GraphQL permet aux clients, en une seule session de communiquer avec le serveur, de répondre aux demandes pour recevoir presque n'importe quoi. Cela peut être contrasté avec l'API Hypermedia, lors de l'utilisation dont vous avez généralement besoin pour effectuer de nombreuses requêtes réseau (parfois, cependant, la
mise en cache peut améliorer la situation).
La capacité de recevoir plusieurs ressources au sein d'une même requête est l'une des forces de GraphQL , sur laquelle les créateurs de cette technologie attirent l'attention de ses utilisateurs potentiels.Beaucoup de ceux qui disent que personne n'a besoin de la technologie GraphQL avec l'avènement de HTTP / 2 signifient cette possibilité. L'utilisation d'API par lots, de langages de requête (tels que GraphQL), l'optimisation des relations et même la création de points de terminaison agrégés semblent désormais moins attrayants qu'auparavant. Le fait est que le "coût" de l'exécution des requêtes devient petit. Et c'est vrai. Mais est-ce seulement pourquoi nous utilisons GraphQL? Je ne pense pas.
Peut-être le fait est que ce sont encore les premiers jours des clients HTTP / 2 et de certaines applications serveur?
Je ne pense pas que la question posée dans le titre de cette section soit une explication valable du fait que nous utilisons encore largement GraphQL. Mais cela vaut la peine d'être mentionné. L'utilisation de HTTP / 2 au niveau de l'application dans certains écosystèmes est un défi qui est loin d'être résolu. Recherchez, par exemple, les mots "Rack / Rails sur HTTP / 2." Ce sera intéressant. Le fait est que de nombreuses parties de serveur d'applications sont construites à l'aide du modèle de demande / réponse. Par conséquent, le passage au concept de flux HTTP / 2 n'est pas si simple. Surtout - dans le cas de certains cadres. Mais c'est une excuse indigne, de nombreux écosystèmes supportent parfaitement un tel schéma d'interaction entre les clients et les serveurs, et, en théorie, nous devrions toujours nous efforcer d'améliorer cette interaction. (La plupart des serveurs proxy prennent également en charge cela, mais il n'est pas facile d'organiser quelque chose comme l'envoi de données à un client à l'initiative du serveur si l'application serveur est bloquée dans le passé en utilisant un modèle de demande / réponse).
GraphQL est plus que de réduire le temps de réception et de transmission des données, ou d'optimiser la quantité d'informations transmises
Bien que la réduction du temps de réception et de transmission des données et l'optimisation de la quantité d'informations transmises soient les points forts de GraphQL dont nous entendons constamment parler, cette technologie nous offre bien plus.
La puissance de la technologie GraphQL réside dans sa concentration sur les systèmes clients. Le client est l'environnement dans lequel GraphQL fait de nombreux compromis. Ces dernières années, cela a dérangé de nombreuses personnes. Ainsi, Daniel Jacobson a écrit de nombreux bons articles sur certains de ces problèmes il y a 5-7 ans.
Ici et
là - quelques-unes de ses publications. Il dit dans l'un d'eux: "Nos API REST, bien qu'elles soient capables de gérer les demandes générales, ne sont optimisées pour aucune de ces demandes."
Veuillez noter que cette idée est valable non seulement lorsqu'elle est appliquée à la technologie REST. Les applications clientes doivent souvent effectuer plus de requêtes serveur que leurs développeurs ne le souhaiteraient. Ces applications doivent gérer la réception de données inutiles des serveurs. Il s'agit davantage de concevoir des API qu'il serait bien de créer afin qu'elles prennent en charge de nombreuses utilisations différentes. La manière habituelle de résoudre ce problème est d'avoir la logique client aussi proche que possible de la logique serveur. Un exemple de cette approche est les adaptateurs client Netflix mentionnés dans
cet article de 2012. Depuis lors, certaines équipes Netflix sont même
passées à GraphQL. Le modèle
BFF vise également à résoudre ces problèmes.
La technologie GraphQL change le concept de la frontière entre le client et le serveur, nous aidant à créer des systèmes de serveur qui peuvent inclure des informations sur la façon dont ils seront utilisés par les clients. Cela se manifeste assez clairement lors de l'utilisation de la technologie des requêtes
constantes , car il s'agit ici, en substance, de ressources serveur générées à l'initiative du client.
Lorsque vous pensez à la pertinence de GraphQL dans le monde HTTP / 2, n'oubliez pas que nous parlons d'abstraction de serveur. La prise en charge de divers cas d'utilisation de données de serveur peut entraîner des problèmes dans les API traditionnelles basées sur les terminaux. GraphQL permet à ceux qui prennent en charge l'API de se concentrer sur l'offre aux utilisateurs de ces API d'un large éventail de fonctionnalités. Dans le même temps, les propriétaires de l'API peuvent ne pas s'inquiéter de la charge croissante des clients existants et du fait que la prise en charge de l'API deviendra beaucoup plus compliquée en raison de la nécessité de prendre en charge de nombreuses ressources différentes. (La prise en charge de nombreuses ressources différentes a ses inconvénients. Par conséquent, de tels schémas compliquent l'optimisation des performances. Ces ressources ne sont pas toujours bien mises en cache. Les API qui peuvent être fortement ajustées sont confrontées aux mêmes problèmes).
Systèmes clients et développement GraphQL
Dans cet article, je parle principalement des serveurs, mais il est important de se rappeler que les développeurs clients sont très friands de la technologie GraphQL. Si vous combinez des fragments GraphQL avec l'approche de composant des frameworks frontaux modernes, vous obtenez une abstraction complètement incroyable. Et, encore une fois, si nous ajoutons des requêtes constantes ici, nous pouvons dire que GraphQL facilite la vie des développeurs de systèmes clients.
GraphQL est un système holistique avec des fonctionnalités remarquables
GraphQL n'est pas quelque chose qui a des capacités complètement uniques. Il existe des alternatives à ce système. Schéma typé? C'est la même chose avec OpenAPI! Abstractions de serveur qui prennent en charge différents cas d'utilisation client? Cela peut être mis en œuvre de plusieurs façons. Introspection? L'utilisation d'Hypermedia permet aux clients de découvrir des actions et de commencer à travailler avec l'entité racine. Un délicieux outil GraphiQL? Je suis sûr que quelque chose de similaire a été créé pour OpenAPI. Les possibilités de GraphQL peuvent toujours être recréées en utilisant d'autres technologies. Cependant, GraphQL est un système holistique. C'est ce qui attire une telle audience de développeurs vers GraphQL qui sont heureux d'utiliser ce système. Je soupçonne que c'est l'une des raisons de la propagation et du développement rapides de GraphQL. De plus, comme la construction de l'API GraphQL est bien documentée, les bibliothèques GraphQL conçues pour différents langages sont généralement de haute qualité et très appréciées.
Le réseautage est toujours un facteur limitant (ou peut-être qu'il en sera toujours ainsi?)
Voici une autre pensée sur laquelle je veux m'arrêter. On a le sentiment que le réseau, lorsqu'il s'agit de travailler avec l'API, jouera toujours le rôle d'un facteur limitant. Peu importe la vitesse à laquelle les requêtes réseau sont effectuées. C'est pourquoi nous ne concevons pas les API Web de la même manière que les objets ordinaires utilisés dans différents langages de programmation.
Ici , par exemple, nous parlons de la raison pour laquelle les interfaces avec un niveau de détail élevé ne conviennent pas très bien pour créer des systèmes conçus pour travailler à distance avec elles.
Bien que HTTP / 2 encourage définitivement l'exécution de requêtes avec une granularité élevée, je pense qu'il y a des compromis à faire ici.
HTTP / 2 peut-il aider GraphQL?
Ainsi, GraphQL fournit au développeur de nombreux outils importants et utiles, mais HTTP / 2 est également une excellente technologie. Regardons l'avenir et réfléchissons aux avantages que les systèmes GraphQL peuvent tirer de l'utilisation de HTTP / 2. Par exemple, cela pourrait ressembler à ceci:
query { viewer { name posts(first: 100) @stream { title } } }
Il s'avère que nous pouvons bien utiliser l'abstraction côté serveur de GraphQL, le langage de requête déclaratif de cette technologie, et en même temps utiliser les capacités des flux HTTP / 2. Je pense que les sockets Web sont utilisées ici. J'ai encore besoin de comprendre cela, mais je suis sûr que beaucoup explorent déjà les directives GraphQL telles que
@defer ,
@stream et
@live .
Résumé
HTTP / 2 est une excellente technologie (et les exemples donnés
ici ne sont qu'une sorte de miracle). GraphQL ne peut être perçu que comme une technologie qui réduit le nombre de sessions de communication client-serveur ou permet d'optimiser le volume des données transmises. Si tel est le cas, tous ceux qui voient GraphQL dans une perspective similaire seront très heureux d'utiliser des API basées sur des capacités HTTP / 2. Cependant, si vous voyez dans GraphQL une combinaison de technologies qui donnent au développeur beaucoup de choses utiles, il devient clair que la puissance de GraphQL ne se limite pas du tout à améliorer l'utilisation des ressources réseau et à économiser du trafic.
Chers lecteurs! Si vous utilisez la technologie GraphQL, dites-nous ce que vous n'aimez pas le plus.
