En résumé
Langage de requête déclaratif pour APIs et runtime d'exécution créé par Facebook, permettant aux clients de demander exactement les données dont ils ont besoin, et rien de plus.
1. Définition détaillée & Contexte d'émergence
GraphQL propose une alternative majeure à REST en exposant généralement un point d'entrée unique (`/graphql`). Le schéma est fortement typé via le Schema Definition Language (SDL). Les requêtes sont formulées par le client sous forme arborescente pour récupérer en un seul aller-retour réseau des données interconnectées (ex: un utilisateur, ses 5 derniers articles et la liste des commentaires associés).
Pourquoi ce concept a été créé : Créé par Facebook pour alimenter son application mobile iOS qui souffrait de multiples requêtes réseau lentes et du surchargement de données ('over-fetching') avec les APIs REST classiques.
2. Composants Clés d’une Architecture GraphQL
Le client prend le contrôle de la forme de la réponse, le serveur se charge de résoudre chaque champ.
1. Schema & Types (SDL)
Contrat strict définissant les types d'objets, les Queries (lecture), les Mutations (écriture) et les Subscriptions (temps réel via WebSockets).
2. Resolvers
Fonctions serveurs chargées de récupérer les données correspondant à chaque champ demandé dans le graphe.
3. Résolution du problème N+1 (DataLoader)
Pattern essentiel regroupant et mettant en cache les requêtes en base de données pour éviter d'exécuter N requêtes individuelles dans une boucle de resolvers.
3. Caractéristiques fondamentales
- Zéro sur-extraction (over-fetching) et zéro sous-extraction (under-fetching).
- Point d’entrée unique (Single Endpoint HTTP POST).
- Documentation et introspection natives (outils GraphiQL, Apollo Studio).
- Subscriptions temps réel natives au protocole.
5. Avantages et limites techniques
Points forts
- ✓Idéal pour les applications mobiles soumises à une bande passante contrainte.
- ✓Regroupement de multiples ressources en une seule requête HTTP.
- ✓Contrat typé strict partagé entre frontend et backend.
Points de vigilance
- ⚠Mise en cache HTTP standard (CDNs) beaucoup plus complexe qu’avec les URLs distinctes de REST.
- ⚠Risque d’attaques par déni de service (DDoS) via des requêtes récursives profondes si non protégées par limitation de profondeur.
6. Recommandations : Quand l'utiliser ?
Idéal pour :
- Applications à données hautement relationnelles nécessitant de combiner plusieurs sources.
- Équipes frontend autonomes devant composer leurs écrans sans attendre de nouveaux endpoints backend REST.
À éviter pour :
- APIs simples avec peu de relations où REST est plus simple à mettre en cache et sécuriser.
- Transferts de fichiers volumineux.
8. Sources officielles vérifiées
Données techniques vérifiées auprès des documentations officielles, des RFCs et des spécifications standards.