GraphQL est un langage de requête open source et un runtime côté serveur qui spécifie comment les clients doivent interagir avec les interfaces de programmation des applications (API).
GraphQL offre une alternative efficace et plus flexible au REST (Representational State Transfer) et aux API RESTful, et résout certaines limitations du REST, en permettant par exemple de cibler plus précisément les ressources avec une seule requête.
GraphQL emploie une syntaxe intuitive qui permet aux clients d’envoyer une seule requête GraphQL à une API et de recevoir exactement les données nécessaires (au lieu d’accéder à des points de terminaison complexes avec de nombreux paramètres). Cette récupération plus efficace des données peut améliorer les performances du système et sa convivialité pour les développeurs.
GraphQL est particulièrement utile pour créer des API dans des environnements complexes dont les exigences front-end évoluent rapidement. Ni les API REST ni les API GraphQL ne sont intrinsèquement supérieures. Ce sont des outils différents qui sont adaptés à des tâches différentes.
Au début des années 2010, Facebook connaît une croissance et une transformation massives. La croissance de sa base d’utilisateurs et un environnement d’application mobile de plus en plus complexe sont autant de facteurs qui commençaient à peser sur son approche RESTful existante, qui nécessitait de multiples allers-retours vers différents points de terminaison d’API pour récupérer toutes les données de requête nécessaires.
Les API REST n’étaient pas équipées pour gérer des interfaces utilisateur complexes basées sur les données, et elles rencontraient souvent des problèmes de latence et d’inefficacité au niveau des données, en particulier pour les utilisateurs mobiles ayant des forfaits de données limités ou coûteux.
Face à ces difficultés, les ingénieurs de Facebook développent GraphQL (ainsi que la plateforme d’applications à page unique React), et le publient sous forme de solution open source en 2015. En 2018, Facebook finit par transférer le service à la GraphQL Foundation, qui comprend des sociétés membres comme AWS, Gatsby, Intuit et IBM.
Les entités déclaratives de récupération des données d’une architecture GraphQL s’articulent autour de plusieurs composants et processus clés, chacun jouant un rôle unique dans la gestion et le traitement des données.
En voici quelques exemples :
GraphQL s’appuie sur un puissant système de types où tous les types de données sont enregistrés dans le langage de définition de schéma (SDL) de GraphQL. Les schémas typés indiquent les types de données qui peuvent faire l’objet d’une requête dans l’API, ainsi que les relations entre les types et les opérations disponibles pour l’utilisateur.
En d’autres termes, ils définissent les capacités de l’API et la forme des données avec lesquelles les clients peuvent interagir. Au final, la configuration de ce schéma détermine l’usage de l’API. Au fur et à mesure que les requêtes arrivent, le schéma est utilisé pour la validation des requêtes et l’API GraphQL n’exécute que celles qui sont validées.
Chaque champ d’un schéma est soutenu par un résolveur qui remplit les données et détermine la réponse à un ensemble de champs. Les résolveurs, qui peuvent récupérer des données à partir d’une base de données, d’un service cloud ou de toute autre source ou presque, fournissent des instructions pour transformer une opération GraphQL (par exemple, une requête, une mutation ou un abonnement) en données.
Lorsqu’un champ de requête démarre, le système génère un appel vers le résolveur correspondant pour produire la valeur suivante. Si un champ produit une valeur scalaire (par exemple, une chaîne ou un nombre), l’exécution se termine. Si un champ génère une valeur d’objet, la requête contient plus de champs pour cet objet. Ce processus se poursuit jusqu’à ce qu’il ne reste que des champs scalaires.
Les résolveurs facilitent également le formatage des données et permettent au système de regrouper les informations provenant de diverses sources de données.
Une requête de données est la requête faite par le client au serveur GraphQL. Elle spécifie les données que le client souhaite récupérer. Les requêtes sont définies dans le type de requête, un objet spécial dans le code qui définit le point d’entrée de niveau supérieur pour chaque requête que les clients peuvent exécuter sur le serveur. Chaque type de requête définit également le nom et le type de retour pour chaque point d’entrée.
Lorsqu’une requête arrive, GraphQL la compare aux définitions du schéma et, si la requête est valide, il l’exécute. La structure d’une requête reflète généralement la structure des données de réponse : les exigences en matière de données sont donc explicites et prévisibles.
Les mutations sont des opérations GraphQL qui créent, mettent à jour ou suppriment des données sur le serveur. Elles sont similaires aux opérations POST, PUT, PATCH et DELETE des API RESTful. Si les utilisateurs peuvent accéder à certaines requêtes sans authentification, les mutations exigent toujours une authentification (par exemple, à l’aide d’un token API).
Comme dans le cas d’une requête, les mutations GraphQL sont comparées au schéma et à ses définitions pour être validées. Une fois la mutation validée et lancée, le serveur renvoie une réponse JSON.
Restez au fait des tendances les plus étonnantes du secteur dans le domaine de l’IA, de l’automatisation, des données et bien d’autres avec la newsletter Think. Consultez la Déclaration de confidentialité d’IBM.
Bien que les API GraphQL soient devenues une alternative plus efficace et plus flexible, REST a longtemps été la norme pour les architectures API. Ce style d’architecture structuré pour les applications hypermédias en réseau est conçu pour utiliser un protocole de communication de type client/serveur sans état (généralement HTTP) pouvant être mis en cache.
Le choix entre GraphQL et REST consiste principalement à déterminer l’outil le mieux adapté à la tâche à accomplir. GraphQL et REST permettent tous deux aux clients de communiquer avec les serveurs et les données de requête, mais certaines différences clés expliquent la prolifération des systèmes GraphQL.
Les API REST sont conçues autour de ressources (par exemple, tout type d’objet, de données ou de service accessible au client), et elles fonctionnent en ayant des points de terminaison différents (URL) pour chaque ressource. Elles utilisent une structure de données fixe pour déterminer la forme et la taille des ressources fournies aux clients.
Lorsque le client demande une ressource, le serveur renvoie un jeu de données contenant toutes les données qui lui sont associées. Si un client a uniquement besoin d’un sous-ensemble de données, il reçoit quand même toutes les données (sur-récupération). Si le client a besoin de données couvrant plusieurs ressources, il doit souvent effectuer plusieurs appels d’API à cause de la récupération inadéquate exécutée à la suite de la requête initiale (sous-récupération).
GraphQL, en revanche, utilise un seul point de terminaison qui fournit une description complète et compréhensible des données. Les requêtes GraphQL peuvent accéder aux propriétés des ressources et suivre les références entre ces dernières. Le client peut ainsi obtenir toutes les données dont il a besoin à partir de la charge utile d’une seule requête API et éviter les problèmes de sur-récupération et de sous-récupération.
Dans une architecture RESTful, changer la structure des données demande souvent aux équipes de mettre à jour la version de l’API pour éviter les erreurs système et les interruptions de service pour l’utilisateur.
Cela signifie que les développeurs doivent créer un nouveau point de terminaison à chaque modification de la structure, ce qui crée plusieurs versions de l’API et complique le processus de maintenance.
GraphQL élimine ce processus de versionnement, car les clients peuvent spécifier leurs demandes dans la requête. Si de nouveaux champs sont ajoutés au serveur, les clients qui n’en ont pas besoin ne seront pas affectés. Inversement, si des champs sont obsolètes, les clients pourront continuer à les interroger jusqu’à la mise à jour de leurs requêtes.
Les API REST utilisent des codes d’état HTTP pour indiquer le statut/la réussite d’une requête. Chaque code d’état a une signification spécifique. Une requête réussie renvoie le code d’état 200, tandis qu’une erreur client peut renvoyer le code d’état 400 et une erreur de serveur le code d’état 500.
GraphQL gère les erreurs différemment. Chaque requête, qu’elle ait entraîné une erreur ou non, renvoie un code d’état OK 200. Les erreurs ne sont pas communiquées à l’aide de codes d’état HTTP : le système communique les erreurs dans le corps de la réponse avec les données.
Cette approche exige que les clients analysent le corps de la réponse pour déterminer si la requête a été exécutée avec succès, ce qui peut rendre le débogage des API GraphQL un peu difficile.
REST ne dispose pas d’une prise en charge intégrée des mises à jour en temps réel. Si une application Web ou mobile a besoin de fonctions en temps réel avec une API REST, les développeurs doivent généralement mettre en œuvre des techniques telles que l’interrogation longue (où le client interroge le serveur de manière répétée à la recherche de nouvelles données), les server-sent events et les WebSockets, qui peuvent ajouter un niveau de complexité à l’application.
En revanche, GraphQL inclut une prise en charge intégrée des mises à jour en temps réel via des abonnements. Les abonnements maintiennent une connexion stable au serveur, permettant au serveur d’envoyer des mises à jour au client chaque fois que des événements spécifiques se produisent et aux clients de maintenir des données API pertinentes.
L’écosystème REST est bien établi. Il met à la disposition des développeurs un large éventail d’outils, de bibliothèques, de cadres et de tutoriels. Cependant, l’utilisation d’API REST exige souvent des équipes qu’elles basculent entre plusieurs points de terminaison et qu’elles comprennent les conventions/schémas uniques de chaque API.
GraphQL est relativement nouveau, mais l’écosystème GraphQL s’est considérablement développé depuis son lancement : divers outils et bibliothèques sont désormais disponibles pour le développement de services front-end et back-end.
Des outils comme GraphiQL, Apollo Studio et GraphQL Playground offrent de puissants environnements de développement intégrés (IDE), directement dans le navigateur, qui permettent d’explorer et de tester les API GraphQL. En outre, GraphQL prend efficacement en charge la génération de code, ce qui peut simplifier le développement côté client.
Les API REST s’appuient sur des mécanismes de mise en cache HTTP comme les ETags et les en-têtes Last-Modified. Bien qu’efficaces, les stratégies de mise en cache peuvent être complexes à mettre en œuvre et ne pas optimiser systématiquement les performances pour tous les cas d’utilisation.
Les API GraphQL peuvent être plus difficiles à mettre en cache en raison de la nature dynamique des requêtes. Toutefois, l’utilisation de requêtes persistantes, de la mise en cache des réponses et de la mise en cache côté serveur peut réduire ces difficultés et représenter des stratégies de mise en cache efficaces pour les architectures GraphQL.
Depuis la transition de GraphQL vers la GraphQL Foundation, les développeurs ont créé des implémentations pour divers langages de programmation, notamment JavaScript, Python, Ruby et PHP, entre autres. Les API GraphQL ont été adoptées par de nombreuses entreprises, comme Github, Pinterest, PayPal, Shopify, Airbnb et d’autres, permettant à davantage de clients de rationaliser les spécifications de données, de réduire la transmission de données réseau excessive ou inadéquate, et d’améliorer les capacités globales de récupération des données.1
De plus, les entreprises et les développeurs militent en faveur d’une fédération ouverte des architectures GraphQL. Dans son itération actuelle, la fédération GraphQL utilise des services GraphQL distincts et les agrège en une seule API GraphQL, qui sert de point d’entrée à toutes les données back-end sous-jacentes et facilite la récupération de données via requête unique. Cependant, l’implémentation de la fédération est réservée à un fournisseur unique.
En réponse à cela, les partisans de GraphQL défendent la fédération démocratisée, qui facilite l’agrégation de données à partir des API GraphQL et non GraphQL, sans se limiter à une agrégation exclusive à GraphQL.2
Créez plus rapidement des API sécurisées et flexibles, avec moins de code, en unifiant les données pour accélérer le développement et l’innovation.
Connectez, automatisez et déverrouillez les silos de données pour débloquer l'innovation et la vitesse avec une Intégration sécurisée et unifiée.
Maximiser la valeur du cloud hybride à l’ère de l’IA générative Accélérer la transformation, moderniser les applications et automatiser l'informatique pour favoriser l'efficacité, la durabilité et l'innovation.
1 IBM acquires GraphQL startup StepZen to step up its game in API Management, TechCrunch, 8 février 2023
2 Why GraphQL Needs an Open Federation Approach, The New Stack, 16 novembre 2023