GraphQL ou REST : quand, pourquoi, comment choisir

Le débat GraphQL vs REST est souvent mal posé. Ce ne sont pas deux concurrents : ce sont deux outils avec des forces différentes. Le bon choix dépend de ton contexte, pas de la hype du moment.

Le problème que GraphQL résout

REST souffre de deux maux classiques :

Over-fetching — tu demandes /users/42 et tu reçois 30 champs alors que tu n'en veux que 3.

Under-fetching — pour afficher un profil avec ses articles, tu fais /users/42 puis /users/42/articles. Deux requêtes pour un seul écran.

GraphQL règle ça avec une seule requête :

query GetUserProfile($id: ID!) {
  user(id: $id) {
    name
    avatar
    articles(first: 5) {
      title
      date
    }
  }
}

Quand choisir REST

REST reste supérieur pour les cas simples : CRUD standard, APIs publiques, cache HTTP natif. Un endpoint /articles bien conçu est plus facile à maintenir, à documenter et à sécuriser qu'un schéma GraphQL.

Quand choisir GraphQL

GraphQL brille quand tu as plusieurs clients (web, mobile, tiers) qui ont besoin de données différentes, ou quand ton modèle de données est fortement interconnecté — en particulier si ta base de données PostgreSQL a de nombreuses relations (réseaux sociaux, e-commerce complexe).

La règle que je suis : commence par REST. Si tu pars sur une architecture Go, construire une API REST en Go est un exercice solide pour comprendre REST dans la pratique. Si tu te retrouves à écrire des dizaines d'endpoints spécialisés pour chaque vue, considère GraphQL.

Les deux coexistent bien — rien n'empêche d'avoir une API REST publique et un endpoint GraphQL interne pour ton frontend.