GraphQL vs REST : un duel qu'il aurait fallu commencer hier
\n\nSituation familière : vous écrivez un nouveau projet en JavaScript (ou Node.js), et soudain la question se pose : que faut-il utiliser pour la communication entre le frontend et le backend ? Le classique REST ou le tendance GraphQL ? Les débats sur ce sujet ne s'apaisent pas, et chaque développeur a son opinion « en béton armé ».
\n\nSoyons honnêtes : REST est un vieil ami fiable qui ne vous a jamais déçu. GraphQL est un nouveau venu audacieux qui promet de résoudre tous vos problèmes. Mais comment choisir ? Je vais vous montrer non pas de simples tableaux de comparaison, mais de véritables exemples concrets en JavaScript. Vous verrez à quoi ressemble le code, où se cachent les pièges et, surtout, quand utiliser quoi.
\n\nD'ailleurs, si vous développez en Python (et ce site parle de Python, n'oublions pas), les principes de choix entre ces technologies sont très similaires. Mais aujourd'hui, nous parlons de JavaScript — le langage qui règne à la fois sur le client et le serveur.
\n\nPetit guide express : REST et GraphQL en 60 secondes
\n\nREST (Representational State Transfer)
\nC'est un style architectural où chaque ressource (utilisateur, article, commentaire) a sa propre URL. Vous faites une requête GET sur /api/users/1 — vous obtenez l'utilisateur. Vous voulez ses articles ? Allez sur /api/users/1/posts. C'est simple, prévisible, mais... parfois un peu trop verbeux.
GraphQL
\nC'est un langage de requête et un environnement d'exécution. Vous avez un seul point de terminaison (généralement /graphql), et vous décidez vous-même quelles données vous souhaitez obtenir. Plus de sur-récupération (quand 50 champs arrivent alors que vous n'en voulez que 3) ni de sous-récupération (quand vous devez faire 5 requêtes pour assembler une page).
Comparaison concrète : écrivons du code en JavaScript
\n\nImaginons une tâche typique : afficher sur une page le profil d'un utilisateur avec ses trois derniers articles. Comparons les deux approches.
\n\nExemple d'API REST avec Express (Node.js)
\n\n// Serveur REST avec Express\nconst express = require('express');\nconst app = express();\n\napp.get('/api/users/:id', (req, res) => {\n // Retourne TOUTES les données de l'utilisateur\n const user = users.find(u => u.id === req.params.id);\n res.json(user); // { id, name, email, phone, address, ... }\n});\n\napp.get('/api/users/:id/posts', (req, res) => {\n // Retourne TOUS les articles de l'utilisateur\n const posts = posts.filter(p => p.userId === req.params.id);\n res.json(posts); // [{ id, title, body, createdAt, ... }]\n});\n\n// Code client (frontend avec fetch)\nasync function loadProfile(userId) {\n // Première requête — on récupère l'utilisateur (beaucoup de données inutiles arrivent)\n const userResponse = await fetch(`/api/users/${userId}`);\n const user = await userResponse.json();\n \n // Deuxième requête — on récupère les articles (encore des données inutiles)\n const postsResponse = await fetch(`/api/users/${userId}/posts`);\n const allPosts = await postsResponse.json();\n \n // On ne prend que les 3 derniers articles\n const latestPosts = allPosts.slice(0, 3);\n \n return { user, posts: latestPosts };\n}\n\nLe problème est évident : nous avons reçu beaucoup de données inutiles (sur-récupération). Pourquoi aurions-nous besoin de l'email, du téléphone, de l'adresse si nous n'affichons que le nom et l'avatar ? Et il peut y avoir 100 articles, alors que nous n'en voulons que 3.
\n\nExemple GraphQL avec Apollo Server (Node.js)
\n\n// Schéma GraphQL\nconst typeDefs = `\n type User {\n id: ID!\n name: String\n avatar: String\n posts(limit: Int): [Post]\n }\n\n type Post {\n id: ID!\n title: String\n body: String\n }\n\n type Query {\n user(id: ID!): User\n }\n`;\n\n// Résolveurs (logique de récupération des données)\nconst resolvers = {\n Query: {\n user: (parent, { id }) => users.find(u => u.id === id),\n },\n User: {\n posts: (parent, { limit }) => {\n let result = posts.filter(p => p.userId === parent.id);\n if (limit) result = result.slice(0, limit);\n