GraphQL : la lune de miel avec l’entreprise est terminée

• GraphQL cherche à résoudre le problème de sur-sollicitation des données, mais dans la plupart des environnements d’entreprise, ce problème est déjà résolu autrement
• Dans les systèmes d’entreprise où l’architecture BFF (Backend for Frontend) est devenue la norme, l’intérêt principal de GraphQL diminue fortement
• Complexité d’implémentation, baisse de l’observabilité, problèmes de cache, contraintes sur les ID, traitement peu pratique des fichiers : autant de facteurs qui alourdissent le coût en production
• REST est simple et rapide, et facilite la gestion des erreurs comme l’onboarding, ce qui le rend plus efficace dans les environnements avec de grandes équipes
• En conclusion, GraphQL est utile dans certains cas, mais constitue un choix excessif pour la plupart des entreprises

---

Le problème que GraphQL cherche à résoudre

• L’objectif central de GraphQL est d’éviter l’overfetching (récupération excessive de données inutiles)
  • Le client ne demande que les champs nécessaires, ce qui réduit les transferts de données inutiles
  • Autre avantage : il n’est pas nécessaire de modifier le backend à chaque nouvelle exigence de l’interface utilisateur
• Mais dans la réalité, cette architecture idéale ne correspond pas à la complexité du terrain

L’overfetching déjà résolu par le BFF

• La plupart des frontends d’entreprise utilisent déjà une couche BFF (Backend for Frontend)
  • Elle assemble les données selon les besoins de l’UI, agrège plusieurs appels downstream et masque la complexité du backend
• Un BFF fondé sur REST peut déjà ne renvoyer que les données nécessaires, ce qui duplique l’avantage de GraphQL
• Si la couche GraphQL récupère ses données depuis des API REST, l’overfetching est simplement déplacé d’un niveau plus bas
• GraphQL peut être utile lorsque plusieurs pages partagent le même endpoint, mais
  • ce bénéfice revient souvent à accepter davantage de configuration et de maintenance pour économiser quelques kilo-octets

Complexité d’implémentation et baisse de productivité

• GraphQL demande beaucoup plus de temps et de complexité d’implémentation que REST
  • Il faut définir le schéma, les types, les resolvers, les sources de données, etc.
  • Il faut aussi maintenir la synchronisation entre le schéma et les clients
• GraphQL optimise la consommation (confort côté client), mais au détriment de la production (vitesse de développement côté serveur)
• En environnement d’entreprise, la vitesse de production et la simplicité sont souvent plus importantes

Problèmes d’observabilité et de monitoring

• Le système de codes de statut HTTP de GraphQL est peu cohérent
  • Une réponse 200 peut contenir des erreurs, ce qui complique la distinction entre succès et échec dans le monitoring
• Avec REST, les 2XX/4XX/5XX permettent une séparation claire, ce qui rend le filtrage dans les dashboards plus intuitif
• Des outils comme Apollo permettent des personnalisations, mais cela entraîne davantage de configuration et de charge mentale
• En cas d’incident en production, identifier le problème est plus difficile et plus complexe qu’avec REST

Les limites concrètes du cache

• Le cache normalisé (normalized caching) d’Apollo est théoriquement puissant, mais en pratique fragile et complexe
  • Deux requêtes qui ne diffèrent que par un seul champ sont traitées séparément, ce qui impose des raccords manuels
  • Le débogage du cache devient un problème à part entière
• À l’inverse, REST peut simplement mettre en cache la réponse complète, ce qui le rend plus stable et plus facile à maintenir

Le problème des contraintes sur les champs ID

• Apollo part du principe que tous les objets possèdent un champ id ou _id
  • Or, de nombreuses API d’entreprise n’ont pas d’ID unique, ou pas d’identifiant global
• Pour s’adapter à cette contrainte, le BFF doit ajouter une logique de génération d’ID locaux
  • Résultat : plus de champs et plus de logique inutiles, ce qui annule en partie le gain sur l’overfetching

L’inefficacité des uploads et téléchargements de fichiers

• GraphQL est mal adapté au traitement des données binaires
  • En pratique, on renvoie une URL de téléchargement et le fichier transite via REST
  • Inclure de gros volumes de données comme des PDF dans une réponse GraphQL dégrade les performances
• Cela brise l’idéal de l’API unique promis par GraphQL

Onboarding et courbe d’apprentissage

• La plupart des développeurs ont beaucoup d’expérience avec REST, alors que GraphQL demande un apprentissage
  • Il faut assimiler de nouveaux concepts : schéma, resolvers, composition des requêtes, règles de cache, gestion des erreurs, etc.
• Cela ralentit l’onboarding des équipes
• REST reste une approche « ennuyeuse mais hautement scalable », donc bien adaptée aux grandes équipes

La complexité de la gestion des erreurs

• Les réponses d’erreur GraphQL sont complexes, avec champs nullable, partial data, tableau errors, codes de statut étendus, etc.
  • Il faut en plus retrouver quel resolver a échoué
• Avec REST, un simple 400 ou 500 suffit souvent, ce qui facilite la compréhension et le débogage

Conclusion : GraphQL reste une technologie de niche

• GraphQL est un outil valable dans certaines situations
  • Mais dans la plupart des environnements d’entreprise, les problèmes sont déjà résolus avec BFF et REST
  • Les vrais enjeux ne sont pas l’overfetching, mais l’observabilité, la fiabilité et la vitesse
• Au final, GraphQL résout un problème étroit au prix d’une complexité plus large
• La conclusion est donc : GraphQL n’est pas mauvais, mais dans la plupart des cas, il n’est pas nécessaire