J'ai eu la chance (ou la malchance) d'utiliser REST, GraphQL et gRPC sur des projets distincts, en production, avec de vraies contraintes. Voici mon analyse sans langue de bois — y compris les erreurs que j'aurais évitées avec ce recul.


Projet 1 : REST avec Django REST Framework


Contexte : marketplace B2B, 4 développeurs, 18 mois.

DRF est mature, documenté, et l'écosystème (drf-spectacular pour OpenAPI, django-filter, simplejwt) couvre 95% des besoins. Les ViewSet permettent un CRUD propre en très peu de code.


Points de friction vécus :


  • Over-fetching sur les endpoints mobile (on récupère 20 champs pour en afficher 3)
  • Versioning fastidieux quand le schéma évolue vite


Ce que j'aurais fait différemment : drf-spectacular dès le début pour la documentation OpenAPI automatique.


Verdict : le choix par défaut pour tout projet Django. Solide, prévisible, maintenable.


Projet 2 : GraphQL avec Strawberry


Contexte : dashboard analytics avec frontend React complexe, 2 développeurs frontend très exigeants.

GraphQL a résolu le over/under-fetching en un seul endpoint flexible. Strawberry (typage Python natif) est excellent.


Points de friction vécus :


  • N+1 queries : sans DataLoader, chaque résolution de champ lance une requête BDD. On a détecté des endpoints qui faisaient 400 queries pour 20 objets.
  • Permissions par champ : complexe à implémenter correctement
  • Debugging en production : les erreurs GraphQL retournent souvent HTTP 200 avec un champ errors


Verdict : pertinent quand le frontend est complexe et que les équipes maîtrisent GraphQL. Surcoût non négligeable sinon.


Projet 3 : gRPC pour communication inter-services


Contexte : communication entre un service Python et deux services Go dans une architecture microservices.

gRPC avec Protobuf est parfait pour ce cas : contrats stricts, performance excellente, support multi-langages natif.


Points de friction vécus :


  • Debugging difficile (format binaire illisible sans outils spécifiques)
  • Pas de support navigateur natif
  • Courbe d'apprentissage des fichiers .proto


Verdict : uniquement pour la communication inter-services, jamais pour les APIs publiques.


La règle de décision que j'applique maintenant


Posez-vous ces questions dans l'ordre :


  1. Plusieurs types de clients (web, mobile, partenaires) avec des besoins différents ? ? GraphQL
  2. Communication interne entre services à haute fréquence ? ? gRPC
  3. Dans tous les autres cas ? REST/DRF

?

Ne sur-estimez pas la complexité de votre cas. 90% des projets Django sont du cas n°3.