GraphQL est un langage de requête open source pour les API, qui permet de récupérer des données provenant de plusieurs sources en un seul appel d’API. Il sert également d’environnement d’exécution côté serveur pour traiter les requêtes à partir des données existantes. GraphQL veille à ne fournir au client que les données demandées, tout en proposant une description complète des données de l’API, et facilite la mise à l’échelle et l’évolution des API.

Comprendre GraphQL

GraphQL a été conçu en privilégiant la flexibilité, la rapidité et les besoins des développeurs. Avec GraphQL, les développeurs peuvent créer des API comme ils l’entendent, puis utiliser une spécification GraphQL pour s’assurer que ces API sont fonctionnelles pour les clients.

L’un des principaux concepts d’une requête GraphQL est que les données reçues sont prévisibles. Au lieu de chaînes de code superflu, le résultat renvoyé correspond exactement à ce qui a été demandé. Cette récupération déclarative des 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, car ce sont elles, et non le serveur, qui contrôlent les données demandées et reçues. Elles restent rapides même lorsque la connexion réseau est lente, puisqu’une seule requête peut renvoyer plusieurs éléments demandés à la fois.

Dans la continuité de la simplification des données offerte par GraphQL, les API sont organisées par types et champs plutôt que par points de terminaison. Toutes les données sont ainsi accessibles depuis un point de terminaison unique, ce qui permet aux applications de demander uniquement ce dont elles ont besoin. En réduisant la complexité opérationnelle, GraphQL s’intègre au workflow d’une solution de connectivité des API rationalisée.

Bref historique

En 2012, Meta (alors Facebook) avait besoin d’une API de récupération de données qui soit suffisamment puissante pour ses applications mobiles Facebook. Sous la direction de Lee Byron, Facebook a développé GraphQL afin de simplifier la récupération de données, notamment du point de vue des concepteurs de produits et des développeurs. GraphQL a d’abord été utilisé en interne par Facebook, avant d’être rendu public et publié en open source en 2015. Suivant la trajectoire de nombreux autres projets open source, le projet GraphQL a rejoint en 2019 sa propre fondation, la GraphQL Foundation, hébergée par la Linux Foundation.

GraphQL a été conçu comme une alternative à l’architecture REST. Les API REST standard nécessitent de charger des informations depuis plusieurs URL au moyen de requêtes HTTP GET distinctes. Avec les API GraphQL, toutes les données sont récupérées au moyen d’une seule requête POST. Bien que REST et GraphQL renvoient tous deux des réponses au format JSON, GraphQL vise à simplifier et à regrouper les données.

Comment fonctionne GraphQL ?

GraphQL prend en charge les requêtes de données précises et permet aux clients de mieux contrôler les informations envoyées. Le client envoie une requête GraphQL sous la forme d’une requête POST, à laquelle le serveur renvoie une réponse au format JSON. GraphQL ne nécessite aucune architecture d’application particulière, peut être déployé dans plusieurs environnements (notamment un environnement de développement intégré [IDE]) et peut être utilisé avec des outils existants de gestion des API ou par-dessus des API REST existantes.

Voici quelques termes clés de GraphQL :

  • Schéma – Créés par les développeurs d’API pour indiquer les données que les clients peuvent interroger, les schémas sont constitués de types d’objets qui définissent ce qu’un client peut demander ainsi que les champs représentant les caractéristiques de l’objet.
  • Requête – Les requêtes sont validées, puis exécutées en fonction du schéma. GraphQL ne peut pas exécuter une requête sans qu’un type d’objet soit défini.
  • Résolveur – Les fonctions de résolution associées à chaque champ du schéma sont appelées afin de produire une valeur lors de l’exécution de l’API. Les résolveurs sont des composants architecturaux essentiels de GraphQL.

L’une des particularités de GraphQL est que les réponses reflètent la structure de la requête (elle-même définie par le schéma). Cela simplifie l’analyse côté client, car le format de la réponse du serveur est entièrement prévisible.

Conception

La nature hiérarchique de GraphQL suit les relations entre les objets et se prête bien aux interfaces utilisateur hiérarchiques. GraphQL 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. Ce fonctionnement est similaire à celui de SQL, où des messages d’erreur explicites s’affichent avant l’exécution d’une requête.

Connecter les résolveurs aux sources de données

Les résolveurs sont les modules architecturaux clés qui relient les champs, les arêtes, les mutations, les requêtes et les abonnements GraphQL aux sources de données (et aux microservices).

Vous pouvez apprendre à créer des résolveurs pour les sources de données AWS dans ce tutoriel GraphQL.

Spécifier les données à récupérer

L’une des particularités des requêtes GraphQL réside dans le fait que les réponses en reflètent la structure. Les données renvoyées par une requête deviennent prévisibles, car vous savez qu’elles correspondront à la structure de la requête adressée à l’API. Lorsque la structure des données renvoyées suit celle de la requête du client, les serveurs s’en trouvent simplifiés.

Avantages de GraphQL

L’un des principaux avantages de GraphQL est qu’il existe des extensions permettant d’ajouter des fonctionnalités qui ne sont pas disponibles avec REST. GraphQL présente également les avantages suivants.

Établit une source unique de vérité

Un schéma GraphQL établit une source unique de vérité dans les applications GraphQL, en fournissant un emplacement central où toutes les données sont décrites. Bien que le schéma GraphQL soit généralement défini sur le serveur, les clients peuvent tout de même interroger et écrire des données en fonction de ce schéma.

Pas de récupération excessive de données

Dans les architectures REST, la récupération excessive de données peut rapidement devenir problématique : 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 s’effectuent en un seul aller-retour et fournissent aux clients les données demandées sans aucune récupération excessive.

Amélioration de la communication entre le client et le serveur

Comme les types de données sont strictement définis, la communication entre le client et le serveur est plus claire avec GraphQL qu’avec REST. Cette structure sous-jacente permet également de se passer de clients complexes pour appeler un serveur GraphQL. Pour en savoir plus et voir des exemples de code en action, consultez la page consacrée aux clients et aux serveurs sur le site officiel de GraphQL.

Évolutif grâce à Federation

Ensemble de principes de conception et d’outils, la fédération d’API permet d’envisager l’exposition des services d’un contexte délimité sous la forme d’une API cohérente pour les utilisateurs, tout en permettant aux services de ce contexte d’évoluer sans contraintes. GraphQL offre une méthode permettant de fédérer l’ensemble de l’API et de la faire évoluer sans rendre les requêtes précédentes incompatibles, assurant ainsi son évolutivité — une des raisons pour lesquelles GraphQL est utilisé par de nombreuses entreprises.

Introspection

La nature introspective de GraphQL permet de récupérer le schéma GraphQL à partir d’une API GraphQL. Les clients peuvent également demander la liste des types de données disponibles, ce qui est idéal pour générer automatiquement de la documentation, ainsi que pour tester ou récupérer des schémas provenant de plusieurs microservices.

Inconvénients de GraphQL

Bien qu’il existe de nombreuses raisons d’adopter GraphQL, il faut également tenir compte de quelques inconvénients. Par exemple, tout n’est pas disponible clé en main : des bibliothèques spécifiques sont nécessaires pour utiliser l’API d’un tiers. De manière générale, GraphQL nécessite également un outillage plus conséquent que REST.

Les inconvénients de GraphQL par rapport à REST sont notamment les suivants.

Courbe d’apprentissage

Pour les développeurs habitués aux API REST, GraphQL présente une courbe d’apprentissage plus abrupte. Il peut également modifier le flux de travail : les équipes chargées des API qui utilisent GraphQL doivent aussi rédiger des schémas GraphQL faciles à maintenir. Cela dit, dans le cadre d’un nouveau projet, GraphQL peut être facile à apprendre et à utiliser, car les requêtes et les réponses ont la même structure.

Stratégies spécifiques de gestion des API

GraphQL peut nécessiter de nouvelles stratégies de gestion des API, tandis que les API REST s’intègrent généralement 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 coûts globaux.

Mise en cache complexe

La mise en cache est moins simple avec GraphQL qu’avec REST, où les requêtes utilisent généralement une méthode HTTP (GET, POST, PUT ou DELETE). Une requête GraphQL standard utilise la méthode POST, qui ne peut pas être mise en cache au niveau HTTP. La mise en cache peut également devenir complexe avec GraphQL, car l’utilisation d’un point de terminaison unique signifie que l’URL de ce point de terminaison produit de multiples réponses variables qui ne peuvent pas être mises en cache (pratique pour récupérer des données, mais peu adapté à la mise en cache). Les développeurs côté serveur finissent alors par différencier les requêtes, même si chacune porte sur le même objet. Cela dit, de nombreuses bibliothèques GraphQL proposent des mécanismes de mise en cache prêts à l’emploi.