Pourquoi j’ai arrêté GraphQL après 6 ans

• Après 6 ans d’utilisation depuis 2018, j’étais un véritable passionné de GraphQL, mais j’ai désormais des réserves
• Je veux expliquer pourquoi je ne recommande plus GraphQL aujourd’hui et quelles alternatives me paraissent meilleures

Surface d’attaque

• GraphQL expose un langage de requête, ce qui présente le risque d’élargir la surface d’attaque.
• Les problèmes liés à l’autorisation sont particulièrement importants.
  • Il faut effectuer des vérifications d’autorisation appropriées pour chaque champ.
  • Avec une API REST, il est plus simple de vérifier les autorisations à chaque endpoint.

Autorisation

• Il faut vérifier les permissions de l’utilisateur pour chaque champ.
• Avec une API REST, il est plus simple de vérifier les autorisations à chaque endpoint.

Limitation de débit

• Les requêtes GraphQL n’ont pas de limite de taille, ce qui peut imposer une lourde charge au serveur.
• Il existe des méthodes pour estimer la complexité d’une requête et limiter celles qui dépassent un certain seuil.
• Avec une API REST, il est plus simple de limiter le nombre de requêtes.

Analyse des requêtes

• Une chaîne de requête invalide peut entraîner une consommation excessive de mémoire côté serveur.
• Il existe une méthode consistant à définir un nombre maximal d’erreurs pour interrompre l’analyse.

Performances

Récupération des données et problème de N+1

• Les field resolvers peuvent appeler plusieurs fois des sources de données externes.
• On peut résoudre ce problème avec le pattern Dataloader.
• Avec REST, il est plus simple de traiter le problème de N+1 dans le contrôleur.

Autorisation et problème de N+1

• Le code d’autorisation peut provoquer un problème de N+1.
• Avec REST, ce problème ne se pose pas.

Couplage

• Dans un codebase GraphQL, la logique métier est fortement couplée à la couche de transport.
• Des tests d’intégration sont nécessaires et le débogage est difficile.

Complexité

• Les différentes méthodes nécessaires pour résoudre les problèmes de sécurité et de performance de GraphQL augmentent la complexité du codebase.
• Les solutions REST sont généralement plus simples.

Alternatives

• Il recommande une API REST JSON utilisant OpenAPI 3.0+.
• Si l’on dispose de clients écrits dans un langage à typage statique, OpenAPI peut être un meilleur choix.
• OpenAPI peut générer automatiquement du code client type-safe.

L’avis de GN⁺

• GraphQL est puissant, mais résoudre ses problèmes de sécurité et de performance demande beaucoup d’efforts.
• Les API REST sont relativement simples et peuvent être plus adaptées dans de nombreux cas.
• OpenAPI fournit de la type safety et des outils automatisés, ce qui peut améliorer la productivité du développement.
• Lorsqu’on adopte GraphQL, il faut prendre pleinement en compte les questions de sécurité et de performance.
• Il est important de comparer les avantages et les inconvénients de REST et de GraphQL afin de choisir la technologie adaptée au projet.

[savvykang]

GraphQL est assez agaçant (2022)

[yangeok]

L’ère du grand retour du RPC arrive.

[ahwjdekf]

Évidemment... Ce n’est pas parce qu’un truc un peu fancy sort qu’il faut se jeter dessus et l’encenser.. Maintenant, c’est au tour des ORM. Ton heure n’est plus très loin non plus...

[rockmkd]

Les ORM existent depuis plus de 20 ans...

[cometkim]

En 2018, les PQ n’étaient déjà plus vraiment une nouveauté (en fait, c’était recommandé dès la première annonce de GraphQL), donc c’est assez surprenant qu’ils n’aient pas essayé pendant 6 ans...

[surfindia]

Il est difficile, pour toutes les raisons évoquées plus haut, d’implémenter GraphQL entièrement à la main, tant du point de vue de la complexité que de la stabilité. Il semble préférable de développer en plaçant une couche comme hasura ou postgraphile au-dessus de la base de données, puis d’y ajouter selon les besoins GraphQL ou REST.

[GN⁺]

Réactions sur Hacker News

• Après avoir adopté GraphQL, ils ont rencontré de nombreux problèmes. À cause de la gestion des autorisations et des problèmes de performances, ils ne veulent plus l’utiliser. Cela peut être bien côté frontend uniquement, mais l’intégration avec le backend est complexe.
• Après avoir d’abord appris REST puis utilisé gRPC, ils ont trouvé l’attrait d’une API avec sûreté de typage. GraphQL n’apporte pas beaucoup d’avantages et n’est utile que lorsqu’il se comporte comme une base de données.
• Ils ont travaillé sur deux projets GraphQL : au départ, tout était petit, mais avec le temps, la complexité a augmenté. Le débogage est difficile et des problèmes de performances apparaissent. REST et RPC sont plus simples et plus faciles à maintenir.
• En tant que fondateur de Hasura, ils ont observé l’évolution de l’usage de GraphQL. GraphQL est très difficile à construire sans couche de données. Utiliser GraphQL au-dessus de REST est inefficace. Son principal cas d’usage est lorsqu’il y a plusieurs consommateurs de données.
• Des ingénieurs frontend stockent les requêtes dans une bibliothèque centrale et les réutilisent, ce qui revient à utiliser GraphQL comme REST.
• D’après leur expérience avec OpenAPI, GraphQL, JSON/HTTP et gRPC, limiter les requêtes GraphQL peut atténuer les problèmes de performances et de sécurité. Buf Connect est le meilleur compromis pour la plupart des projets.
• D’après leur expérience de GraphQL chez Facebook, beaucoup de gens n’ont pas réellement le problème que GraphQL cherche à résoudre. Facebook l’utilise pour gérer le versionnage et des modèles d’objets complexes.
• Si GraphQL fonctionne bien chez Facebook, c’est parce que tous les utilisateurs sont connectés et que la sécurité est intégrée à chaque champ. GraphQL peut être utile dans le cas d’une SPA avec authentification obligatoire.
• Après avoir utilisé GraphQL, cela semblait bien au début, mais a fini par nécessiter beaucoup de travail supplémentaire et de redondance. Il aurait été préférable de commencer avec des endpoints de type JSON-RPC et d’ajouter les fonctionnalités nécessaires.
• En l’utilisant sur un petit projet, presque tout leur a plu. Ils ont utilisé Apollo Client et graphql-codegen pour générer des types et des fonctions pour Vue 3. Il y a eu quelques problèmes, mais cela a permis de détecter beaucoup d’erreurs au niveau du typage.