GraphQL
Définition
Alternative à REST où le client définit précisément les données qu'il veut récupérer en une seule requête. Plus complexe à mettre en place mais évite le sur-fetching sur les écrans riches.
Comment ça marche
En GraphQL, le client envoie une requête qui décrit exactement les données qu'il veut, dans la forme qu'il veut. Le serveur expose un schéma typé (queries pour lire, mutations pour écrire, subscriptions pour le temps réel), et l'API renvoie strictement ce qui a été demandé. Tout passe par un seul endpoint, généralement /graphql, accessible en POST. Le typage est fort de bout en bout : un client peut générer ses types TypeScript à partir du schéma serveur, ce qui élimine toute classe d'erreurs liées aux désynchros entre client et back.
À quoi ça sert
GraphQL brille sur les interfaces complexes qui agrègent beaucoup de données reliées : réseau social, dashboard analytique, marketplace avec données partenaires, outils internes riches. On évite le sur-fetching (recevoir des champs inutiles) et l'under-fetching (faire plusieurs allers-retours) typiques d'une API REST. Sur mobile en particulier, où la bande passante coûte cher, le gain est significatif. Pour les apps qui ont plusieurs frontaux (web, mobile, partenaires) avec des besoins de données différents, GraphQL évite de maintenir plusieurs APIs spécialisées en parallèle.
Quand l'utiliser
GraphQL devient pertinent quand vous avez : plusieurs clients différents qui consomment la même API avec des besoins variés, des UIs très agrégées qui combinent dix sources de données par écran, une équipe front-end importante qui veut itérer sans demander de modifications au back-end. Pour ces cas, l'investissement initial dans l'outillage GraphQL paie. À l'inverse, pour une app B2B classique avec une UI à charge raisonnable et un seul client (le front web), REST reste plus simple à mettre en place et à maintenir.
L'écosystème
Côté serveur, on utilise Apollo Server, GraphQL Yoga, Pothos pour TypeScript, ou des solutions intégrées comme Hasura et PostGraphile qui génèrent une API GraphQL à partir d'une base PostgreSQL. Côté client, Apollo Client et urql gèrent le cache, les requêtes et le state management. La codegen génère des hooks React typés à partir des queries écrites en .graphql. Sur Next.js, on peut servir un endpoint GraphQL via une route API, mais l'écosystème natif Next.js (Server Components, Server Actions) couvre désormais la plupart des cas qui justifiaient GraphQL il y a quelques années.
Les coûts cachés
GraphQL coûte plus cher à mettre en place et à sécuriser correctement. Trois sujets demandent une attention particulière. Les autorisations au niveau du champ : un utilisateur a-t-il le droit de lire ce sous-champ précis ? On l'implémente via des résolveurs avec contexte. La protection contre les requêtes coûteuses : un client malveillant peut envoyer une query profondément imbriquée qui coûte des secondes de CPU et de DB, on limite la profondeur et la complexité. Le caching : plus subtil qu'en REST, on combine cache client (Apollo) et persisted queries pour bénéficier du cache HTTP traditionnel.
Les pièges à éviter
Trois pièges classiques. Le N+1 sur les resolvers : un champ de liste qui déclenche une requête base par enfant explose les performances, on utilise DataLoader pour batcher. La paginatio mal pensée : on passe au cursor-based dès le départ pour rester scalable. L'absence de monitoring : sans observabilité fine (quelles queries sont lentes, quelles erreurs côté client), GraphQL devient une boîte noire en production. On installe Apollo Studio, Hasura Cloud ou un APM compatible dès le premier déploiement. Et on documente les conventions de naming pour éviter la dérive du schéma.