GraphQL est un langage de requête open-source pour API qui permet d’extraire des données de plusieurs sources en un seul appel d’API. Il agit également comme moteur d’exécution côté serveur pour remplir des requêtes avec des données existantes. GraphQL donne la priorité au client en lui fournissant uniquement les données demandées tout en fournissant une description complète des données de l’API, ce qui facilite la mise à l’échelle et l’évolution des API.
GraphQL a été conçu dans un souci de flexibilité, de rapidité pour les développeurs. Il permet aux développeurs de créer librement des API puis d’utiliser une spécification GraphQL pour s’assurer que les API soient adaptés aux clients.
L’un des principaux concepts d’une requête GraphQL est que les données de retour sont prévisibles. Plutôt que des chaînes de code excédentaires, les retours correspondent exactement à la demande. Cette extraction déclarative de données est particulièrement utile sur les appareils mobiles, où la bande passante est limitée. Les applications qui utilisent GraphQL sont également stables et rapides parce qu’elles contrôlent les données demandées et reçues, plutôt que le serveur. Elles sont également rapides même sur les connexions réseau lentes, parce qu’une seule requête peut renvoyer plusieurs éléments demandés en même temps.
En s’appuyant sur la simplification des données de GraphQL, les API sont organisées par types et par champs plutôt que par points de terminaison. Cela signifie que toutes les données sont accessibles à partir d’un seul point de terminaison, ce qui permet aux applications de ne demander que ce qui est nécessaire. En réduisant la complexité opérationnelle, GraphQL s’intègre dans le flux de travail d’une solution de connectivité d’API rationalisée.
En 2012, Meta (alors Facebook) avait besoin d’une API de récupération de données suffisamment puissante pour ses applications mobiles Facebook. Sous la direction de Lee Byron, Facebook a développé GraphQL pour simplifier la récupération de données, en particulier du point de vue des concepteurs et des développeurs de produits. GraphQL a d’abord été utilisé en interne par Facebook, puis rendu public et open-source en 2015. Suivant la trajectoire de nombreux autres projets open-source, en 2019, le projet GraphQL a été transféré à sa propre Fondation GraphQL, hébergée par la Fondation Linux.
GraphQL a été conçu comme une alternative à l’architecture REST. Les API REST standard nécessitent le chargement d’informations à partir de plusieurs URL via des requêtes HTTP GET distinctes. Avec les API GraphQL, toutes les données sont récupérées via une requête POST unique. Même si REST et GraphQL renvoient tous deux des réponses au format JSON, GraphQL se concentre sur la rationalisation et la consolidation des données.
GraphQL prend en charge les demandes de données granulaires et permet aux clients de mieux contrôler les informations envoyées. Le client envoie une requête GraphQL sous forme d’une requête POST à laquelle le serveur renvoie une réponse au format JSON. GraphQL ne nécessite pas d’architecture d’application spécifique. Il peut être déployé dans de nombreux environnements (y compris un environnement de développement intégré [IDE]) et peut être utilisé avec des outils de gestion d’API existants ou en complément des API REST existantes.
Voici quelques termes clés liés à GraphQL :
Une caractéristique unique de GraphQL est que les réponses reflètent la structure de la requête (qui est elle-même définie par le schéma), ce qui simplifie l’analyse pour le client, car le format de la réponse du serveur est totalement prévisible.
La nature hiérarchique de GraphQL suit les relations entre les objets et fonctionne bien dans les interfaces utilisateur hiérarchiques. Il est également fortement typé, ce qui signifie que chaque niveau de requête correspond à un type. Ces types définissent ensuite un ensemble de champs. Cela lui confère une similarité à SQL, pour lequel des messages d’erreur descriptifs sont affichés avant l’exécution d’une requête.
Les résolutions constituent des modules architecturaux clés qui relient les champs GraphQL, les périphéries, les mutations, les requêtes et les abonnements aux sources de données (et aux microservices).
Vous pouvez apprendre à établir des résolutions pour les sources de données AWS dans ce tutoriel GraphQL.
L’une des particularités des requêtes GraphQL réside dans les réponses en miroir. Les données renvoyées par une requête deviennent prévisibles, car vous savez qu’elles correspondront à la forme de la demande de l’API. Lorsque la forme des données renvoyées correspond à la requête du client, les serveurs sont simplifiés.
L’un des principaux avantages de GraphQL réside dans la disponibilité d’extensions pour fournir des fonctionnalités indisponibles dans REST. Ses autres avantages sont les suivants.
Un schéma GraphQL constitue une source unique de vérité dans les applications GraphQL, en fournissant un emplacement principal où toutes les données sont décrites. Bien que le schéma GraphQL soit généralement défini au niveau du serveur, les clients peuvent toujours interroger et écrire des données sur la base du schéma.
Dans les architectures REST, la surextraction peut rapidement devenir un problème : l’application (backend) définit les données disponibles pour chaque ressource et les renvoie toutes dans sa réponse, même si le client (frontend) n’a besoin que d’un seul élément. Les appels GraphQL se font en un seul voyage et fournissent aux clients les données demandées sans surextraction.
Les types de données étant fortement définis, la communication entre le client et le serveur est plus claire dans GraphQL que dans REST. Cette structure sous-jacente signifie également que des clients complexes ne sont pas nécessaires pour appeler un serveur GraphQL. Pour en savoir plus sur les clients et les serveurs, et pour voir le code en action, consultez la page officielle de GraphQL.
Ensemble de principes et d’outils de conception, la fédération d’API permet d’exposer des services dans un contexte délimité sous forme d’une API cohérente pour les utilisateurs, tout en permettant aux services dans ce contexte d’évoluer sans restrictions. GraphQL offre une méthode pour fédérer l’ensemble de l’API et pour le faire évoluer sans interrompre les requêtes précédentes pour sa mise à l’échelle. Cette évolutivité est l’une des raisons pour lesquelles GraphQL est utilisé par de nombreuses entreprises.
La nature introspective de GraphQL permet de récupérer le schéma GraphQL à partir d’une API GraphQL. Les clients peuvent également demander une liste des types de données disponibles, ce qui est idéal pour générer automatiquement une documentation et pour tester ou récupérer des schémas à partir de plusieurs microservices.
S’il y a de nombreuses raisons d’adopter GraphQL, il y a aussi quelques inconvénients à connaître. Par exemple, tout n’est pas prêt à l’emploi. Des bibliothèques spéciales sont nécessaires pour utiliser une API tierce. En outre, dans l’ensemble, GraphQL nécessite un support d’outils plus lourd que REST.
Voici les inconvénients de GraphQL par rapport à REST.
Pour les développeurs habitués aux API REST, GraphQL s’accompagne d’une courbe d’apprentissage plus raide. Il peut également modifier le flux de travail, les équipes API utilisant GraphQL devant également écrire des schémas GraphQL faciles à maintenir. Cela dit, si vous commencez de zéro, GraphQL peut être facile à apprendre et à utiliser, car les requêtes et les réponses ont la même structure.
GraphQL peut nécessiter de nouvelles stratégies de gestion des API, alors que les API REST ont tendance à s’adapter aux modèles de gestion des API existants. Il est important d’en tenir compte, car l’ajout d’une nouvelle stratégie de gestion des API peut augmenter les dépenses globales.
La mise en cache est moins simple dans GraphQL que dans REST, où les requêtes utilisent généralement une méthode HTTP (GET, POST, PUT ou DELETE). POST, la requête GraphQL standard ne peut pas être mise en cache au niveau HTTP. La mise en cache peut également devenir complexe dans GraphQL parce que le fait d’avoir un seul point de terminaison signifie que l’URL de ce point de terminaison produit de multiples réponses variables qui ne peuvent pas être mises en cache (ce qui représente un avantage pour récupérer des données, mais un inconvénient pour la mise en cache). Les développeurs de serveurs finissent alors par avoir des requêtes différentes, même si chacune opère dans le même objet. Cela dit, de nombreuses bibliothèques GraphQL offrent des mécanismes de mise en cache intégrés.