GraphQL fait beaucoup parler depuis quelques années, présenté comme le successeur de REST. Mais est-ce vraiment le cas ? Après avoir implémenté les deux approches en production, voici un guide pragmatique pour faire le bon choix.
La promesse GraphQL vs la réalité terrain
Ce qu’on vous vend :
- “Plus d’overfetching/underfetching”
- “Un seul endpoint pour tout”
- “Les clients demandent exactement ce dont ils ont besoin”
La réalité en production :
- Complexité de mise en cache accrue
- N+1 queries si pas bien géré
- Courbe d’apprentissage pour l’équipe
- Coût de monitoring et debugging plus élevé
Quand REST est le meilleur choix
1. APIs publiques et third-party
REST excelle pour les APIs publiques car :
- Caching HTTP natif (CDN, browser cache)
- Standards bien établis (OpenAPI/Swagger)
- Outils debugging universels (curl, Postman)
- Pas de limite de requête complexe
Exemple concret : Stripe, Twilio, GitHub utilisent REST pour leurs APIs publiques.
2. CRUD simple et prévisible
Si vos ressources sont bien définies et stables :
// REST : Simple et clair
GET /users/123
PUT /users/123
DELETE /users/123
// Pas besoin de GraphQL pour ça
3. Équipe junior ou contraintes de temps
REST nécessite moins de montée en compétence :
- Concepts simples (HTTP verbs, status codes)
- Debugging facile
- Moins de choix architecturaux à faire
Quand GraphQL devient pertinent
1. Agrégation multi-sources complexe
GraphQL brille quand vous agrégez plusieurs sources :
query DashboardData {
user(id: "123") {
name
orders(limit: 5) {
id
total
items {
product {
name
category
}
}
}
recommendations {
products {
id
name
}
}
}
}
En REST : Cela nécessiterait 4-5 appels API + logique côté client.
2. Applications mobiles avec contraintes réseau
Réduire le nombre de requêtes est critique sur mobile :
- Latence réseau variable (3G/4G/5G)
- Batterie économisée
- Bande passante limitée
Cas réel : L’app mobile de notre client e-commerce est passée de 12 requêtes à 1 seule avec GraphQL, réduisant le temps de chargement de 40%.
3. Frontend-Backend fortement couplés
Si vos équipes frontend/backend collaborent étroitement :
- Itération rapide sur les besoins data
- Schema-first development
- Type safety bout-en-bout (avec TypeScript)
Approche hybride : le meilleur des deux mondes
En 2025, l’approche hybride est de plus en plus courante :
Pattern 1 : REST pour les mutations, GraphQL pour les queries
// Mutations simples : REST
POST /api/orders
PUT /api/users/123
// Queries complexes : GraphQL
POST /graphql
{
query {
orderDetails(id: "456") {
...
}
}
}
Avantages :
- Caching HTTP pour les mutations (POST/PUT/DELETE)
- Flexibilité GraphQL pour les queries complexes
- Simplicité REST pour les opérations standard
Pattern 2 : REST + GraphQL Gateway
Architecture que j’ai mise en place chez un client :
┌─────────────┐
│ Clients │
└──────┬──────┘
│
┌──────▼──────────┐
│ GraphQL Gateway │ ← Fédération de services REST
└──────┬──────────┘
│
┌───┴────┬────────┬─────────┐
│ │ │ │
┌──▼──┐ ┌──▼──┐ ┌───▼───┐ ┌───▼────┐
│Users│ │Orders│ │Products│ │Billing│
│REST │ │REST │ │REST │ │REST │
└─────┘ └─────┘ └───────┘ └────────┘
Résultat :
- Services backend simples (REST)
- Frontend bénéficie de GraphQL
- Migration progressive possible
Checklist de décision pragmatique
Choisissez REST si :
✅ API publique ou third-party ✅ CRUD simple et bien défini ✅ Équipe junior ou contraintes de temps ✅ Caching HTTP essentiel ✅ Ressources stables et prévisibles
Choisissez GraphQL si :
✅ Agrégation multi-sources complexe ✅ Application mobile avec contraintes réseau ✅ Frontend-Backend fortement couplés ✅ Besoins data évoluent rapidement ✅ Équipe mature et temps d’investissement disponible
Questions à se poser :
Qui consomme l’API ?
- Public/Third-party → REST
- Vos propres apps → GraphQL possible
Complexité des requêtes ?
- Simples et prévisibles → REST
- Complexes et variables → GraphQL
Maturité de l’équipe ?
- Junior/mixte → REST
- Senior avec temps d’apprentissage → GraphQL
Contraintes réseau ?
- Réseau stable (web) → REST OK
- Mobile/contraintes → GraphQL avantageux
Budget infrastructure ?
- Serré → REST (moins de ressources)
- Confortable → GraphQL possible
Pièges à éviter
Piège GraphQL n°1 : N+1 queries
# Sans DataLoader : N+1 queries !
query {
users {
id
orders { # ← Query par user !
id
}
}
}
Solution : Toujours utiliser DataLoader ou équivalent.
Piège GraphQL n°2 : Queries trop complexes
Limiter la profondeur et la complexité :
// Dans votre config Apollo Server
const server = new ApolloServer({
validationRules: [
depthLimit(5), // Max 5 niveaux
createComplexityLimitRule(1000) // Max 1000 de complexité
]
});
Piège REST n°1 : Overfetching systématique
Ne pas hésiter à créer des endpoints spécialisés :
// Au lieu de GET /users/123 qui retourne TOUT
GET /users/123/profile // Données profil only
GET /users/123/orders // Commandes only
GET /users/123/summary // Vue résumée
Piège REST n°2 : Trop d’endpoints custom
Équilibrer entre générique et spécialisé :
❌ GET /users/123/orders/last-week/with-products-and-reviews
✅ GET /users/123/orders?since=2025-08-15&include=products,reviews
Métriques de succès
Pour évaluer votre choix :
Performance
- Temps de réponse p50/p95/p99
- Nombre de requêtes par page
- Taille payload (compression)
Developer Experience
- Temps ajout nouvelle feature
- Nombre de bugs liés à l’API
- Satisfaction équipe (sondages)
Coûts
- Coût infrastructure (compute, réseau)
- Temps de développement
- Dette technique
Conclusion : Pas de silver bullet
La vérité :
- REST n’est pas mort
- GraphQL n’est pas une solution miracle
- L’hybride est souvent la meilleure approche
Mon conseil :
- Commencez simple (REST)
- Identifiez les pain points réels
- Introduisez GraphQL progressivement si besoin
- Mesurez l’impact sur vos métriques métier
En 2025, le débat REST vs GraphQL est dépassé. La vraie question est : quelle combinaison résout le mieux vos problèmes spécifiques ?
Et vous, quelle approche utilisez-vous ? Partagez vos retours d’expérience !