GraphQL : Langage de requête pour les API

GraphQL : Demander exactement ce dont vous avez besoin

Avez-vous déjà utilisé une API qui renvoyait trop de données, ou pas assez ? C'est le problème que GraphQL a été conçu pour résoudre. Au lieu que le serveur décide des données à envoyer, le client demande exactement ce dont il a besoin et ne reçoit que cela. C'est comme commander à la carte plutôt que de recevoir un menu fixe.

Comment fonctionne GraphQL

Au cœur de GraphQL se trouve un schéma — une description de toutes les données disponibles et de la manière dont elles sont connectées. Le schéma est fortement typé, ce qui signifie que chaque donnée a un type spécifique : chaîne, nombre, booléen, ou des types plus complexes comme les objets et les listes. Ce schéma agit comme un contrat entre le client et le serveur.

Les clients envoient des requêtes qui décrivent exactement ce qu'ils veulent. Par exemple, une requête peut demander le nom et l'e-mail d'un utilisateur, ainsi que ses commandes les plus récentes. Le serveur répond avec un objet JSON qui correspond à la forme de la requête — pas de données supplémentaires, pas de champs manquants. Cela élimine à la fois le sur-écrémage (obtenir des données dont vous n'avez pas besoin) et le sous-écrémage (devoir effectuer plusieurs requêtes pour obtenir toutes les données nécessaires).

Requêtes, mutations et abonnements

GraphQL propose trois types d'opérations. Les requêtes sont utilisées pour lire les données — elles sont l'équivalent des requêtes GET. Les mutations sont utilisées pour écrire des données — créer, mettre à jour ou supprimer des ressources. Les abonnements sont destinés aux mises à jour en temps réel — le serveur envoie des données au client dès qu'un changement se produit, comme de nouvelles notifications ou des messages de chat en direct.

Résolveurs : comment les données sont récupérées

Côté serveur, chaque champ du schéma possède une fonction résolveur qui sait comment récupérer ces données. Les résolveurs peuvent appeler des bases de données, des API externes ou calculer des valeurs à la volée. Ils reçoivent l'objet parent, les arguments, un contexte (qui contient généralement l'authentification et les connexions à la base de données) et des informations sur la requête. GraphQL appelle les résolveurs de manière sélective — il n'exécute que les résolveurs pour les champs qui ont été réellement demandés.

Un défi courant est le problème N+1, où la récupération d'une liste d'éléments, puis la récupération d'un champ associé pour chaque élément, entraîne de nombreuses requêtes à la base de données. La solution est DataLoader, qui regroupe et met en cache les requêtes afin que plusieurs résolveurs ayant besoin des mêmes données puissent partager une seule requête à la base de données.

Fédération : combiner plusieurs services

Pour les grandes organisations, un schéma GraphQL unique peut devenir difficile à gérer. La fédération vous permet de diviser le schéma entre plusieurs services, chacun responsable de son propre domaine. Une passerelle les combine en un graphe unifié unique avec lequel les clients interagissent. Cela permet aux équipes indépendantes de posséder leur partie de l'API tout en présentant une expérience cohérente aux consommateurs.

GraphQL vs REST : quand utiliser chacun

GraphQL excelle lorsque vous avez des relations de données complexes, plusieurs clients avec des besoins différents, et que vous souhaitez itérer rapidement sans versioning. REST est plus simple et plus mature, avec une mise en cache native, un support d'outillage plus large et une courbe d'apprentissage plus facile. Pour de nombreux projets, la meilleure approche est de commencer par REST et de passer à GraphQL lorsque la complexité le justifie.

GraphQL n'est pas un remplacement de REST — c'est un outil différent pour des problèmes différents. Comprendre les deux vous permet de choisir le bon outil pour chaque situation.