backend / graphql
Pourquoi GraphQL face à REST
Explication
Un peu d'histoire
GraphQL naît en 2012 à l'intérieur de Facebook, dans l'équipe mobile menée par Lee Byron, Nick Schrocker et Dan Schafer. Le problème est concret : la nouvelle application iOS du fil d'actualité doit afficher des données très imbriquées (posts, commentaires, likes, profils) et l'API REST existante oblige à multiplier les appels réseau, ce qui rend l'app lente sur des connexions mobiles 3G peu fiables. L'équipe invente un langage de requête où le client décrit exactement la forme de données dont il a besoin, en un seul aller-retour. Facebook l'utilise en interne pendant trois ans avant de l'ouvrir au public en 2015. Depuis 2018, la spécification est maintenue par la GraphQL Foundation, hébergée par la Linux Foundation, indépendamment de Facebook (devenu Meta).
Pourquoi apprendre GraphQL aujourd'hui
GraphQL est aujourd'hui utilisé en production par GitHub (toute son API publique v4), Shopify, X (Twitter), Airbnb, PayPal ou encore Netflix. Sur le marché de l'emploi, la mention GraphQL apparaît de plus en plus dans les offres backend et fullstack, en particulier dès qu'un produit a une app mobile et un frontend web qui doivent consommer des données différemment de la même API. Savoir concevoir un schéma GraphQL propre, gérer le problème du N+1 avec DataLoader, ou sécuriser un endpoint contre les requêtes abusives, sont des compétences directement valorisées dans les postes API/backend modernes, souvent en complément (et non en remplacement) de REST.
Ce que vous allez apprendre
- Comprendre les deux problèmes concrets que GraphQL résout : le sur-fetching et le sous-fetching
- Lire une requête et une réponse GraphQL, et voir pourquoi la réponse "calque" toujours la requête
- Distinguer les situations où REST reste préférable à GraphQL (cache HTTP, fichiers binaires)
- Comprendre le rôle central du schéma typé comme contrat entre client et serveur
- Te repérer dans le reste du cours : schéma, resolvers, mutations, temps réel, sécurité, fédération
Dans quel contexte ?
Imagine une application mobile de e-commerce qui doit afficher la fiche d'un produit avec son nom, son prix, sa catégorie, ses avis clients et l'auteur de chaque avis. En REST, cela demande généralement plusieurs appels séparés (GET /produits/42, puis GET /produits/42/avis, puis un appel par auteur d'avis), chacun avec de la latence réseau. En GraphQL, une seule requête vers /graphql décrit toute cette arborescence et le serveur renvoie exactement ces champs, en un aller-retour.
D'abord, le problème du sur-fetching
Une API REST classique expose un endpoint comme GET /utilisateurs/42, qui renvoie l'objet utilisateur complet : nom, email, date d'inscription, préférences, biographie... même si l'écran qui a déclenché l'appel n'affiche que le nom. C'est ce qu'on appelle le sur-fetching : le client reçoit plus de données qu'il n'en a besoin, ce qui gaspille de la bande passante, surtout sur mobile.
Ensuite, le problème inverse : le sous-fetching
À l'opposé, un écran qui a besoin de données réparties sur plusieurs ressources (l'utilisateur, ses articles, les commentaires de ces articles) doit enchaîner plusieurs requêtes REST successives, chacune attendant la réponse de la précédente. C'est le sous-fetching : une seule ressource REST ne suffit jamais, il faut "sous-fetcher" plusieurs endpoints à la chaîne.
Il reste un problème à régler : comment le client choisit-il précisément ce qu'il veut ?
C'est exactement ce que fait GraphQL : au lieu d'endpoints figés qui renvoient une forme de données fixe, un seul endpoint (/graphql) accepte une requête qui décrit la forme exacte attendue. Le serveur exécute cette requête et renvoie une réponse JSON qui a très précisément la même structure imbriquée que la requête envoyée.
| Critère | REST | GraphQL |
|---|---|---|
| Nombre d'endpoints | Un par ressource | Un seul (/graphql) |
| Qui décide des champs renvoyés | Le serveur | Le client, requête par requête |
| Versionnement de l'API | /v1, /v2 | Évolution du schéma, sans version dans l'URL |
| Cache HTTP natif (CDN, navigateur) | Oui, via GET | Non, car POST par défaut |
Prérequis
Aucune connaissance de GraphQL n'est nécessaire, mais tu dois être à l'aise avec le concept d'API HTTP et le format JSON — c'est le socle sur lequel toute cette leçon s'appuie.
Piège fréquent
Beaucoup de débutants pensent que GraphQL doit remplacer complètement REST. En pratique, REST reste souvent préférable pour des fichiers binaires (images, PDF), du contenu qui bénéficie d'un cache HTTP/CDN simple (une page publique peu personnalisée), ou des webhooks tiers qui parlent nativement REST. GraphQL et REST cohabitent très bien dans une même architecture.
Maintenant que tu comprends pourquoi GraphQL existe, la prochaine étape logique est de voir comment on décrit les données qu'une API GraphQL expose : c'est le rôle du schéma, écrit en SDL (Schema Definition Language), sujet de la prochaine leçon.
Commandes & code
Pourquoi GraphQL face à REST
# REST : plusieurs endpoints, souvent sur/sous-fetching
GET /utilisateurs/42 -> tout l'objet utilisateur, même les champs inutiles
GET /utilisateurs/42/articles -> requête séparée pour les articles (2 aller-retours)
GET /articles/7/commentaires -> encore une requête pour les commentaires (3 aller-retours)# GraphQL : un seul endpoint, un seul aller-retour, exactement les champs demandés
query {
utilisateur(id: "42") {
nom
articles {
titre
commentaires {
contenu
auteur { nom }
}
}
}
}// La réponse a EXACTEMENT la forme de la requête -- pas plus, pas moins
{
"data": {
"utilisateur": {
"nom": "Alice",
"articles": [
{
"titre": "Introduction à GraphQL",
"commentaires": [
{ "contenu": "Super article !", "auteur": { "nom": "Bob" } }
]
}
]
}
}
}Comparatif rapide
| Critère | REST | GraphQL |
|-----------------------|------------------------------------|-----------------------------------|
| Endpoints | Multiples (un par ressource) | Un seul endpoint (/graphql) |
| Sur/sous-fetching | Fréquent | Éliminé (champs choisis par client)|
| Versionnement | /v1, /v2 ... | Évolution du schéma sans version |
| Cache HTTP | Natif (GET + CDN) | Plus complexe (POST par défaut) |
| Typage | Non standardisé (OpenAPI optionnel) | Schéma fortement typé obligatoire |Résumé
- GraphQL résout le sur-fetching (trop de champs) et le sous-fetching (plusieurs requêtes nécessaires).
- Un seul endpoint HTTP, le client décide de la forme exacte de la réponse via la requête.
- Le schéma typé sert de contrat explicite entre client et serveur, avec introspection intégrée.
- REST reste pertinent pour du cache HTTP simple ou des ressources binaires (fichiers, uploads).
Exercices pratiques
Mission : trancher entre REST et GraphQL pour l'appli mobile e-commerce
Objectif : Diagnostiquer le sur/sous-fetching d'un flux REST existant et concevoir la query GraphQL qui le remplace en un seul aller-retour.
Contexte
L'équipe mobile de la fiche produit enchaîne aujourd'hui GET /produits/42, puis GET /produits/42/avis, puis un appel par auteur d'avis pour afficher le nom, le prix, la catégorie et les avis clients avec leur auteur. Sur une connexion 3G, cette suite d'appels est lente. Ton rôle : diagnostiquer précisément le problème, puis concevoir la requête GraphQL qui le règle — sans pour autant migrer aveuglément toute l'API.