Une brève visite de GraphQL

Bonjour, Habr!


Le livre d' Alex Banks et Eva Porsello, que nous avons donné à la traduction il y a quelques jours, vous servira de brève digression dans le langage de requête GraphQL. Le livre des mêmes auteurs sur React et Redux est devenu un véritable best-seller (nous attendons le 5ème tirage de l'imprimerie). Soit dit en passant, merci à tous ceux qui nous ont signalé des inexactitudes dans le code et les termes;) nous avons fait le livre sur une technologie si rapidement obsolète trop rapidement.

L'auteur de l'article d'aujourd'hui, Robin Viruch, travaille également sur un livre sur GraphQL et les bibliothèques pour ce langage, et dans l'article d'aujourd'hui explique brièvement les avantages et les caractéristiques de GraphQL comme alternative à REST



Lorsqu'il s'agit de requêtes réseau entre les applications client et serveur, REST est le plus souvent choisi comme pont entre les mondes client et serveur. Dans REST, tout se développe autour de l'idée «nous avons besoin de ressources accessibles par URL». Vous pouvez lire une ressource à l'aide d'une HTTP GET , créer une ressource à l'aide d'une demande HTTP POST , la mettre à jour et la supprimer à l'aide HTTP PUT demandes HTTP PUT et DELETE . Ces opérations sont appelées CRUD (Créer, Lire, Mettre à jour, Supprimer). La ressource peut être tout contenu reçu des auteurs, des utilisateurs ou extrait d'articles. Lorsque vous utilisez REST, le format de transfert de données n'est pas codé en dur, mais le plus souvent JSON est utilisé à cet effet. Au final, REST permet la communication entre les applications via le protocole HTTP normal en utilisant des URL et des méthodes HTTP.

 //    REST GET https://api.domain.com/authors/7 //   JSON { "id": "7", "name": "Robin Wieruch", "avatarUrl": "https://domain.com/authors/7", "firstName": "Robin", "lastName": "Wieruch" } 

Bien que REST soit resté un standard de facto pendant un certain temps, une autre technologie développée par Facebook a gagné en popularité ces dernières années: elle s'appelle GraphQL. Cet article, une introduction à GraphQL, parle des avantages et des inconvénients de ce langage de requête.

Qu'est-ce que GraphQL?

Avant de plonger dans la discussion sur les forces et les faiblesses de GraphQL, répondons d'abord à la question suivante: qu'est-ce que GraphQL? GraphQL est un langage de requête freeware créé par Facebook en 2012. Avant même de soumettre le produit à l'open source, la langue était déjà utilisée sur Facebook comme technologie interne pour travailler avec des applications mobiles. Pourquoi avec des applications mobiles? GraphQL a été développé comme une alternative à l'architecture REST typique. Il permet au client de demander uniquement les données souhaitées - ni plus, ni moins. Le client est responsable de tout, c'est-à-dire de vous. Dans ce cas, des difficultés surviennent dans l'architecture REST, car c'est l'interface de base de données qui détermine les informations qui seront disponibles pour chaque ressource à chaque URL. L'échantillonnage des données n'est pas demandé dans la partie client. Par conséquent, le frontend doit dans tous les cas demander toutes les informations sur la ressource, même s'il n'a besoin que d'une partie de ces données. Ce problème est appelé «rééchantillonnage». Dans le pire des cas, l'application cliente doit lire non seulement une, mais plusieurs ressources, pour l'accès auquel il est nécessaire d'effectuer de nombreuses requêtes réseau. Cela conduit non seulement à un rééchantillonnage, mais également à des demandes de type avalanche sur le réseau. Cependant, ayant un langage de requête tel que GraphQL, utilisé non seulement sur le serveur, mais aussi sur le côté client, le client décide des données dont il a besoin - et pour cela envoie une seule demande au serveur. Lorsque Facebook a développé des applications mobiles en utilisant le langage GraphQL, il a été possible de réduire considérablement la charge du réseau, car beaucoup moins de données ont commencé à être transmises via celui-ci.

Facebook a publié la spécification GraphQL et son implémentation de référence en JavaScript pour un accès gratuit. Depuis lors, cette spécification a été implémentée dans de nombreux autres langages de programmation majeurs. De plus, l'écosystème qui s'est développé autour de GraphQL se développe non seulement horizontalement, se propageant à d'autres langages de programmation, mais aussi verticalement (les bibliothèques sont construites au-dessus de GraphQL, par exemple, Apollo, Relay).

GraphQL fournit les types d'opérations suivants: demande (lecture), modification (écriture) ou abonnement (lecture continue). Chacune de ces opérations n'est qu'une chaîne qui doit être assemblée conformément aux spécifications du langage de requête GraphQL. Une fois qu'une telle opération GraphQL arrive dans l'application de base de données à partir de l'application cliente, elle peut être interprétée en comparaison avec l'ensemble du schéma GraphQL situé sur le backend et résolue pour l'application cliente à l'aide des données disponibles. GraphQL fonctionne aussi bien avec n'importe quelle couche réseau (qui est souvent organisée via HTTP), qu'avec n'importe quel format de charge utile (souvent JSON). Il est également totalement «non concerné» par l'architecture de l'application (qui dans la plupart des cas se compose de la partie client et de l'interface de base de données). C'est juste un langage de requête.

 //  GraphQL author(id: "7") { id name avatarUrl articles(limit: 2) { name urlSlug } } //   GraphQL { "data": { "author": { "id": "7", "name": "Robin Wieruch", "avatarUrl": "https://domain.com/authors/7", "articles": [ { "name": "The Road to learn React", "urlSlug": "the-road-to-learn-react" }, { "name": "React Testing Tutorial", "urlSlug": "react-testing-tutorial" } ] } } } 

Comme vous pouvez le voir, la requête s'applique déjà à de nombreuses ressources (auteur, article), appelées champs dans GraphQL, et uniquement à un ensemble spécifique de champs imbriqués pour ces champs (nom, urlSlug pour l'article), bien que d'autres données puissent être fournies dans le schéma de données GraphQL lui-même Informations (par exemple, pour un article - une description, la date de sortie). Alors que dans une architecture REST, nous aurions besoin d'au moins deux requêtes en cascade pour récupérer l'auteur et les articles de cet auteur, GraphQL résout ce problème en une seule requête. En outre, la requête sélectionne uniquement les champs nécessaires et non l'entité entière.

C'est l'essence de GraphQL. Dans le cas où l'application serveur fournit le schéma GraphQL dans lequel elle définit toutes les données disponibles avec sa hiérarchie et ses types, l'application cliente ne demande que les données dont elle a besoin.

Avantages GraphQL

Voici les principaux avantages de l'utilisation de GraphQL dans une application.

Échantillonnage déclaratif des données

Comme vous pouvez le voir, GraphQL utilise l'échantillonnage déclaratif des données dans ses requêtes. Le client sélectionne les données, ses entités et tous les champs entre lesquels il existe différentes relations, et pour tout cela une seule demande est appliquée. Le client décide quels champs sont nécessaires pour cette interface utilisateur. Souvent, vous pouvez presque parler d'échantillonnage de données orienté interface utilisateur. Par exemple, c'est ainsi qu'Airbnb utilise GraphQL. Un moteur de recherche Airbnb fournit souvent des résultats pour les maisons, les impressions et d'autres catégories spécifiques à un sujet donné. Pour extraire toutes les données en une seule fois, une requête GraphQL est exécutée, ne récupérant que les informations qui sont définitivement nécessaires dans une interface utilisateur particulière. Au final, la répartition des responsabilités est parfaitement organisée dans GraphQL: le client connaît les exigences en matière de données, le serveur connaît la structure des données et comment résoudre les données à partir d'une source existante (que ce soit une base de données, un microservice, une API tierce).

Pas de rééchantillonnage lorsque vous travaillez avec GraphQL

Lorsque vous travaillez avec GraphQL, il n'y a pas de resélection. Alors qu'un client mobile est susceptible de frapper une nouvelle récupération en utilisant la même API qu'un client Web avec une API REST. Et lorsque vous travaillez avec GraphQL, le client mobile et le client Web peuvent choisir différents groupes de champs pour eux-mêmes, en utilisant la même API GraphQL. Par conséquent, le client mobile peut sélectionner moins d'informations, car des informations inutiles peuvent ne pas être nécessaires sur le petit écran (contrairement au grand écran à partir duquel la version Web de l'application est visualisée). GraphQL minimise la quantité de données transmises sur le réseau, en les sélectionnant de manière sélective et en étant guidé dans ce cas principalement par les besoins de l'application cliente.

GraphQL pour React, Angular, Node, etc.

GraphQL est une solution prometteuse non seulement pour les développeurs React. Que ce soit Facebook qui l'emporte sur GraphQL, et côté client, Facebook utilise React, en fait, ce langage n'est lié à aucune solution pour le frontend ou le backend. L'implémentation de référence de GraphQL est écrite en JavaScript, afin que GraphQL puisse être combiné avec Angular, Vue, Express, Hapi, Koa et d'autres bibliothèques JavaScript dans les parties client et serveur. De plus, cela ne s'applique pas seulement à l'écosystème JavaScript. GraphQL imite REST sous un aspect, grâce auquel il est devenu populaire: l'interface GraphQL est indépendante du langage de programmation (langage de requête) utilisé pour communiquer deux objets (par exemple, client et serveur). Par conséquent, sa spécification peut être reproduite dans n'importe quel langage de programmation.

Qui utilise GraphQL?

Facebook utilise GraphQL depuis 2012, avant que ce langage ne devienne open source. Facebook est le moteur qui est responsable du développement de la spécification GraphQL et de son implémentation de référence en JavaScript. Donc, en travaillant avec GraphQL, vous êtes déjà sur les épaules de géants. Cependant, d'autres sociétés bien connues utilisent ce langage dans leurs applications. Ils investissent dans l'écosystème GraphQL, car les applications modernes ont grand besoin d'un tel langage. Ainsi, vous serez soutenu non seulement par Facebook, mais aussi par les entreprises suivantes:

• GitHub [1] [2]
• Shopify [1] [2]
• Twitter
• Coursera
• Yelp
• Wordpress
• L a new york times
• Samsara
• et d' autres ...

Lorsque Facebook a développé GraphQL et l'a rendu public, d'autres sociétés d'applications mobiles ont également rencontré des problèmes similaires. C'est ainsi que Netflix a créé le projet Falcor, qui peut être considéré comme une alternative à GraphQL. Ce qui confirme une fois de plus que pour les applications modernes, vous avez besoin exactement de solutions telles que GraphQL et Falcor.

La seule source de vérité

Dans les applications GraphQL, la vérité ultime existe: c'est le schéma GraphQL. C'est elle - la source centrale, qui décrit toutes les données disponibles. Alors que le schéma GraphQL est généralement défini côté serveur, les clients peuvent lire (interroger) et écrire (modifier) ​​des données basées sur ce schéma. Ainsi, l'application serveur, essentiellement, fournit les informations exhaustives disponibles sur le serveur, et le côté client ne demande que ce qui est requis pour formuler des requêtes dans GraphQL, ou modifie de petits fragments d'informations en utilisant les modifications dans GraphQL.

GraphQL suit les tendances actuelles

GraphQL suit les tendances actuelles du développement d'applications. Vous ne pouvez avoir qu'une seule application sur le backend, mais il arrive souvent que de nombreux clients différents utilisent ce backend (client web, appareil mobile, montres intelligentes ...) et tous dépendent des données stockées dans l'application backend. Par conséquent, GraphQL peut aider non seulement à se faire des amis des «deux mondes», mais également à satisfaire les exigences de chaque client (liées, par exemple, à l'utilisation du réseau, aux relations de données imbriquées, en sélectionnant uniquement les données requises) sans avoir à créer une API dédiée pour chaque type de client.

D'un autre côté, sur le serveur, nous ne pouvons pas attendre une seule interface interne, mais un groupe de microservices, chacun fournissant ses propres fonctionnalités spécifiques. C'est dans un tel cas que le schéma GraphQL est idéalement adapté, dont la structure est telle que dans un tel schéma GraphQL il est possible d'agréger toutes sortes de fonctionnalités.

Comment le schéma GraphQL se raccorde

Grâce à la couture, vous pouvez assembler un schéma parmi de nombreux autres. Quand puis-je me retrouver dans cette situation? Disons que votre backend est implémenté à l'aide d'une architecture de microservice. Chaque microservice traite la logique métier et les données liées à un domaine spécifique. Par conséquent, chaque microservice peut définir son propre schéma GraphQL. Après cela, vous devrez les coudre ensemble pour assembler l'un de tous les schémas auxquels l'application client accédera. Au final, chaque microservice peut avoir son propre terminal GraphQL, et une passerelle API GraphQL consolidera tous les schémas en un seul global pour le fournir aux applications clientes.

Introspection GraphQL

GraphQL Introspection est la possibilité d'extraire un schéma GraphQL avec l'API GraphQL. Étant donné que le schéma contient toutes les informations sur toutes les données disponibles via l'API GraphQL, il peut être utilisé avec grand succès pour la génération automatique de la documentation de l'API. Cependant, la question ne se limite pas à documenter l'API; l'introspection peut également être utilisée pour simuler un schéma GraphQL sur une application cliente (à des fins de test) ou pour récupérer des schémas à partir de plusieurs microservices, puis les assembler.

GraphQL fortement typé

GraphQL est un langage de requête hautement typé écrit dans le langage de définition de schéma expressif (SDL) pour GraphQL. Ce langage présente les mêmes avantages que tout langage de programmation fortement typé. Il est moins sujet aux erreurs, peut être validé au moment de la compilation et peut être compté pour l'intégration avec les fonctionnalités IDE / éditeur prises en charge telles que la saisie semi-automatique et la prise en charge des entrées.

Versionnement de GraphQL

GraphQL ne dispose pas de ces versions d'API auxquelles nous sommes habitués dans REST. Dans REST, il est normal de proposer plusieurs versions de la même API (par exemple api.domain.com/v1/, api.domain.com/v2/), car les ressources ou leur structure peuvent changer au fil du temps. Dans GraphQL, vous pouvez traduire des API en non-recommandées au niveau du champ. Par conséquent, le client reçoit un avertissement lorsqu'il accède à un champ non recommandé. Après un certain temps, le champ non recommandé peut être exclu du schéma, alors plus aucun client ne l'utilisera. Ainsi, l'API GraphQL peut être développée sans avoir besoin de versionner.

Écosystème GraphQL en croissance

L'écosystème GraphQL se développe. Il ne s'agit pas seulement d'intégrations avec des éditeurs et des IDE liés à la nature fortement typée de GraphQL; pour GraphQL en tant que tel, il existe de nouvelles applications à part entière. Par exemple, vous pouvez rappeler Postman, qui était utilisé lorsque vous travailliez avec l'API REST, et maintenant dans le même but, mais avec l'API GraphQL, GraphiQL ou GraphQL Playground est utilisé. Il existe également diverses bibliothèques pour vous, par exemple, Gatsby.js, un générateur de site Web statique pour React qui utilise GraphQL. Par exemple, Gatsby.js vous permet d'écrire un moteur de blog qui remplit votre blog de contenu lors de la création via l'API GraphQL. Par conséquent, vous aurez également des CMS sans partie client (par exemple GraphCMS) fournissant du contenu (pour un blog) via GraphQL. API Cependant, non seulement les composants technologiques se développent dans ce domaine. Comme les champignons poussent après la pluie, les conférences, mitaps et communautés consacrées à GraphQL sont également faciles à trouver sur les newsletters et podcasts.

Si je passe à GraphQL - est-ce que je fais tapis?

En ajoutant GraphQL à la pile technologique existante, nous n'allons bien sûr pas à tapis. Migration d'une application back-end monolithique vers une architecture de microservices, le plus important est de substituer l'API GraphQL aux nouveaux microservices. En effet, c'est précisément en présence de nombreux microservices que vous et votre équipe pouvez implémenter en toute sécurité la passerelle GraphQL, assembler des schémas et les consolider en un schéma global. Mais la passerelle API peut être utilisée non seulement avec des microservices, mais également avec une application REST monolithique. C'est ainsi que vous pouvez combiner toutes vos API sur une seule passerelle et migrer pas à pas vers GraphQL.

Inconvénients de GraphQL

Ensuite, nous discutons de certains des inconvénients associés à l'utilisation de GraphQL.

Complexité des requêtes GraphQL

Parfois, GraphQL n'est pas utilisé correctement, j'essaie de le remplacer par une base de données côté serveur. Non, ça ne marchera pas. GraphQL n'est qu'un langage de requête. Lorsque du côté serveur, la demande doit être résolue avec des données, il existe généralement une implémentation indépendante de GraphQL qui donne accès à la base de données. GraphQL est indifférent dans ce cas. De plus, GraphQL n'élimine aucun goulot d'étranglement des performances lorsque vous devez traiter un grand nombre de champs (auteurs, articles, commentaires) dans une seule requête. Quelle que soit l'architecture dans laquelle la demande a été effectuée - RESTful ou GraphQL, vous devez toujours extraire divers champs de la source.

Ainsi, nous aurons un problème si le client envoie immédiatement un ensemble de demandes à l'ensemble des champs imbriqués. Souvent, les développeurs côté client ne savent pas combien de requêtes de base de données différentes doivent être traitées dans l'application serveur si des appels de données en masse commencent. C'est dans de tels cas qu'un mécanisme est nécessaire (par exemple, la profondeur de requête maximale, peser la complexité des requêtes, éviter la récursivité, les requêtes constantes) pour empêcher le flux de requêtes trop coûteuses du client.

Limite de vitesse dans GraphQL

Un autre problème est la limitation de vitesse. Alors que dans REST, il est relativement simple de dire «pas plus de requêtes sont autorisées par jour», il est difficile de formuler une telle instruction pour des opérations GraphQL individuelles, car il y a non seulement des opérations «coûteuses» et «non coûteuses», mais aussi de nombreuses graduations intermédiaires. C'est dans de tels cas que les entreprises fournissant des API GraphQL publiques proposent leurs propres calculs de limite de vitesse , souvent réduits aux valeurs maximales susmentionnées de profondeur de requête et de pondération de la complexité des requêtes.

Mise en cache GraphQL

Lorsque vous travaillez avec GraphQL, l'implémentation d'un cache simplifié est beaucoup plus compliquée que dans REST. Lorsque nous travaillons avec REST, nous accédons aux ressources par URL et, par conséquent, pouvons organiser la mise en cache au niveau des ressources, car l'URL de ressource peut servir d'identifiant. Dans GraphQL, c'est compliqué car toutes les requêtes peuvent être différentes, même si tout le monde opère sur le même objet. Dans une demande, vous pouvez demander le nom de l'auteur, et dans la suivante - non seulement le nom de l'auteur, mais aussi son adresse e-mail. C'est dans de tels cas que vous aurez besoin d'un cache plus en filigrane au niveau du champ, et ce n'est pas si simple à mettre en œuvre. Cependant, la plupart des bibliothèques construites sur GraphQL offrent de tels mécanismes de mise en cache dès la sortie de la boîte.

Pourquoi pas REPOS?

GraphQL – REST, . REST – GraphQL, REST?
REST URL , . «», id, , id. GraphQL , . , , , GraphQL , .

, REST. Airbnb. , . REST-, REST- . , , GraphQL API, GraphQL, (, ), (., ).

, GraphQL ; , , , . GraphQL – Facebook , -.

, , REST – . , GraphQL. , GraphQL, - .