GraphQL

Rédigé par David Brulin, co-fondateur de Quai des Balises

GraphQL est un langage de requête pour API qui permet au client de demander précisément les données dont il a besoin, ni plus ni moins, via un point d'accès unique. Le serveur répond avec une structure JSON calquée sur la requête, ce qui réduit les allers-retours réseau et le sur-chargement de données.

Comment fonctionne GraphQL

GraphQL repose sur un schéma typé qui décrit l'ensemble des données disponibles et leurs relations. Le client envoie une requête à un point d'accès unique (souvent /graphql) en décrivant la forme exacte de la réponse attendue ; le serveur renvoie un JSON correspondant champ pour champ.

Trois types d'opérations structurent les échanges :

Query : lecture de données, sans effet de bord.
Mutation : création, modification ou suppression de données.
Subscription : flux temps réel, le serveur poussant les mises à jour au client.

Le schéma sert aussi de contrat et de documentation : il valide les requêtes en amont et permet aux outils d'introspecter automatiquement l'API. Cela rend l'API auto-descriptive, un atout pour les équipes front et back qui travaillent en parallèle.

GraphQL face à REST

REST expose plusieurs points d'accès, un par ressource, et renvoie une structure de réponse fixe. GraphQL expose un point d'accès unique et laisse le client composer sa réponse. Les deux approches sont valides : le choix dépend de la complexité des données et des besoins clients.

Critère	GraphQL	REST
Points d'accès	Un seul (endpoint unique)	Multiples, un par ressource
Sélection des données	Le client choisit les champs	Structure de réponse fixe
Over/under-fetching	Évité par construction	Fréquent, nécessite des appels multiples
Typage / contrat	Schéma typé fort, introspection native	Variable, dépend d'OpenAPI/Swagger
Mise en cache HTTP	Complexe (POST, endpoint unique)	Native via verbes et URL (GET)
Courbe d'apprentissage	Plus élevée au démarrage	Plus simple, largement répandue

GraphQL brille quand des clients hétérogènes (web, mobile) consomment des données aux besoins différents, ou quand les relations entre entités sont profondes. REST reste pertinent pour des API simples, fortement orientées cache ou aux ressources bien délimitées.

Quand l'adopter en projet métier

Pour une plateforme métier, un ERP ou une application multi-clients, GraphQL réduit le nombre d'appels réseau et donne au front la maîtrise de ses besoins sans dépendre d'évolutions côté serveur. Il évite la multiplication d'endpoints spécifiques à chaque écran.

Quelques points de vigilance avant d'adopter GraphQL :

Mise en cache : moins immédiate qu'avec REST, elle se gère côté applicatif ou via des couches dédiées.
Requêtes coûteuses : une requête trop profonde peut surcharger le serveur ; prévoir une limitation de complexité.
Sécurité et autorisations : à appliquer finement au niveau des champs, pas seulement de l'endpoint.
Maturité de l'équipe : l'outillage et la conception du schéma demandent une montée en compétence initiale.

En pratique, le choix se décide selon la complexité des données, le nombre de clients à servir et les contraintes de performance, pas par effet de mode.

Questions fréquentes

Non, GraphQL ne remplace pas REST : ce sont deux approches complémentaires. REST reste adapté aux API simples et fortement mises en cache, tandis que GraphQL excelle quand des clients variés ont des besoins de données différents. Le choix dépend du contexte du projet, pas d'une supériorité absolue.

Non, GraphQL est indépendant du stockage. C'est une couche de requête qui s'interface avec n'importe quelle source : base SQL, NoSQL, autres API ou microservices. Les résolveurs du serveur GraphQL traduisent les requêtes vers ces sources, ce qui le rend agnostique vis-à-vis de la persistance.

GraphQL n'est ni plus ni moins sûr par nature ; la sécurité dépend de l'implémentation. Il faut gérer les autorisations au niveau des champs, limiter la profondeur et la complexité des requêtes, et valider les entrées. Mal configuré, son endpoint unique peut exposer des requêtes coûteuses ou des données sensibles.

Une query lit des données sans les modifier, comparable à une lecture seule. Une mutation crée, met à jour ou supprime des données, avec effet de bord côté serveur. Cette séparation explicite clarifie l'intention de chaque opération et facilite la gestion des droits et de la mise en cache.

Vos clients mobiles ont des besoins de données variés ? GraphQL peut être la bonne réponse.

Voir nos logiciels sur mesure

Définitions liées

← Retour au glossaire