GraphQL

GraphQL est un langage de requête pour API qui permet à un client de demander exactement les données dont il a besoin en un seul appel, au lieu d'interroger plusieurs endpoints REST à structure fixe. Créé par Facebook en 2012 et open-sourcé en 2015, il est aujourd'hui utilisé par des entreprises comme GitHub, Shopify ou Twitter pour servir des clients web et mobiles depuis une seule couche d'API flexible.

Qu'est-ce que GraphQL ?

GraphQL est à la fois un langage de requête et un moteur d'exécution de ces requêtes contre un schéma qui décrit les données et les relations d'une API. Contrairement à une API REST classique, où chaque endpoint renvoie une structure de données fixe, une API GraphQL expose un seul point d'entrée et laisse le client décrire exactement les champs qu'il veut, y compris imbriqués entre objets liés, en une seule requête.

Comment fonctionne une requête GraphQL

Un client envoie une requête qui reflète la forme de la réponse attendue :

query {
  user(id: "42") {
    name
    email
    orders {
      id
      total
    }
  }
}

Le serveur résout chaque champ via une fonction appelée resolver, et renvoie une réponse JSON qui a exactement la forme de la requête, ni plus ni moins. L'écriture de données fonctionne de la même façon via une mutation, une opération nommée qui modifie l'état et renvoie les champs mis à jour demandés par le client.

Les briques de base

• Schéma : le contrat qui définit chaque type, champ et relation disponible dans l'API.
• Query : une opération de lecture qui récupère des données sans rien modifier côté serveur.
• Mutation : une opération d'écriture qui crée, modifie ou supprime des données.
• Subscription : une connexion persistante qui pousse des mises à jour au client en temps réel.
• Resolver : la fonction côté serveur qui récupère la valeur réelle d'un champ du schéma.

GraphQL vs API REST

Quand utiliser GraphQL

GraphQL justifie sa complexité quand un client a besoin de données imbriquées et liées en un seul aller-retour, quand plusieurs types de clients (web, iOS, Android) ont besoin de tranches différentes des mêmes données, ou quand la bande passante est limitée et que le sur-chargement de données coûte cher. C'est généralement excessif pour une application CRUD simple avec un seul client et quelques ressources plates, où une API REST classique ou un backend-as-a-service comme Supabase ou Firebase suffit et va plus vite à mettre en place. Le piège le plus courant est le problème N+1, où une configuration naïve des resolvers déclenche une requête base de données par champ imbriqué ; on le résout avec des outils de batching comme DataLoader. La mise en cache demande aussi des outils dédiés, car un point d'entrée GraphQL unique ne peut pas s'appuyer sur le cache HTTP simple qu'autorisent des URLs REST distinctes. Une équipe qui adopte GraphQL doit aussi prévoir du temps pour la conception du schéma, car un schéma mal pensé est plus difficile à corriger ensuite qu'un endpoint REST bâclé, justement parce que les clients dépendent de sa forme exacte dès le premier jour.

GraphQL chez BeBranded

Nous utilisons GraphQL quand une application web sert plusieurs clients depuis les mêmes données (un tableau de bord, une app mobile, une API publique) et que chacun doit récupérer seulement ce dont il se sert, sans multiplier les endpoints. Il s'appuie généralement sur une base comme Supabase ou Firebase, qui gère le stockage pendant que GraphQL façonne la façon dont chaque client lui parle.