Y a-t-il des inconvénients à GraphQL? [fermé]

101

Tous les articles sur GraphQL vous diront à quel point c'est merveilleux, mais y a-t-il des inconvénients ou des lacunes? Je vous remercie.

rest  restful-authentication  graphql 
— Dr Nemo
source

Réponses:

96

Désavantages:

  • Vous devez apprendre à configurer GraphQL. L'écosystème évolue encore rapidement, vous devez donc suivre le rythme.
  • Vous devez envoyer les requêtes du client, vous pouvez simplement envoyer des chaînes mais si vous voulez plus de confort et de mise en cache, vous utiliserez une bibliothèque cliente -> code supplémentaire dans votre client
  • Vous devez définir le schéma au préalable => travail supplémentaire avant d'obtenir des résultats
  • Vous devez avoir un endpoint graphql sur votre serveur => nouvelles bibliothèques que vous ne connaissez pas encore
  • Les requêtes Graphql sont plus d'octets que d'aller simplement à un point de terminaison REST
  • Le serveur doit effectuer plus de traitement pour analyser la requête et vérifier les paramètres

Mais, ceux-ci sont plus que contrés par ceux-ci:

  • GraphQL n'est pas si difficile à apprendre
  • Le code supplémentaire ne fait que quelques Ko
  • En définissant un schéma, vous éviterez beaucoup plus de travail après avoir corrigé des bugs et enduré des mises à niveau poilues
  • Il y a beaucoup de gens qui passent à GraphQL donc il y a un riche écosystème en développement, avec un excellent outillage
  • Lorsque vous utilisez des requêtes persistantes en production (en remplaçant les requêtes GraphQL par simplement un ID et des paramètres), vous envoyez en fait moins d'octets qu'avec REST
  • Le traitement supplémentaire pour les requêtes entrantes est négligeable
  • Fournir un découplage propre de l'API et du backend permet une itération beaucoup plus rapide sur les améliorations du backend
— w00t
source
1
"Vous devez définir le schéma au préalable => travail supplémentaire avant d'obtenir des résultats" Je ne vois pas en quoi cela n'est pas nécessaire sans GraphQL? Bien sûr, avec certains frameworks dans certains langages, ce n'est pas obligatoire, mais par exemple pour une API Java, vous devrez toujours décrire le "schéma" dans vos modèles.
— AntoineB
3
@AntoineB vous avez raison, dans NodeJS cependant vous pouvez facilement créer une API REST sans jamais penser au schéma global; retournez simplement les choses.
— w00t
1
@ w00t et dès que vous aurez besoin de certains paramètres avec REST, vous aurez recours à l'analyse de l'URL pour vérifier que le type du paramètre est correct, en lançant un 400 si ce n'est pas le cas. Si seulement il y avait quelque chose pour éviter d'avoir à le faire manuellement dans chaque gestionnaire de route: D
— Capaj
Avec Spring Boot, vous pouvez simplement extraire des artefacts graphql-spring-boot-starteret graphql-java-toolscommencer. Créez votre schéma dans la ressource .graphqls et créez des classes Resolver et vous avez terminé. Pour qu'un exemple de test fonctionnel soit opérationnel, il a fallu environ 10 minutes.
— Babyburger
1
Je ne suis pas d' accord sur tous les inconvénients, en fait il vous permet d' économiser beaucoup de temps de vérifier ce poste xalitech.com/graphql-how-to-convince-your-boss
— Shafqat Ali
59

J'ai trouvé des préoccupations importantes pour quiconque envisage d'utiliser GraphQL , et jusqu'à présent, les principaux points sont:

Requête en profondeur indéfinie : GraphQL ne peut pas interroger en profondeur indéfinie, donc si vous avez un arbre et que vous souhaitez renvoyer une branche sans connaître la profondeur, vous devrez faire une pagination.

Structure de réponse spécifique : dans GraphQL, la réponse correspond à la forme de la requête, donc si vous devez répondre dans une structure très spécifique, vous devrez ajouter une couche de transformation pour remodeler la réponse.

Cache au niveau du réseau : en raison de la façon dont GraphQL est généralement utilisé sur HTTP (un POST dans un seul point de terminaison), le cache au niveau du réseau devient difficile. Un moyen de le résoudre consiste à utiliser des requêtes persistantes.

Gestion du téléchargement de fichier : Il n'y a rien sur le téléchargement de fichier dans la spécification GraphQL et les mutations n'acceptent pas les fichiers dans les arguments. Pour le résoudre, vous pouvez télécharger des fichiers en utilisant d'autres types d'API (comme REST) ​​et transmettre l'URL du fichier téléchargé à la mutation GraphQL, ou injecter le fichier dans le contexte d'exécution, de sorte que vous aurez le fichier dans les fonctions du résolveur.

Exécution imprévisible : La nature de GraphQL est que vous pouvez interroger en combinant les champs de votre choix, mais cette flexibilité n'est pas gratuite. Il est bon de connaître certaines préoccupations telles que les performances et les requêtes N + 1.

API super simples : dans le cas où vous avez un service qui expose une API vraiment simple, GraphQL ne fera qu'ajouter une complexité supplémentaire, donc une API REST simple peut être meilleure.

— Bruno Soares
source
2
Pour une profondeur indéfinie, je recourt aux réponses JsonType. Ce n'est pas fortement typé, vous devez donc vérifier les entrées, mais cela peut être très pratique.
— w00t
3
REST a toujours eu un problème de requêtes N + 1. La seule différence est que, de par sa conception, REST interdit au backend de tenter même de résoudre le problème. Au lieu de cela, il pousse le problème sur le frontend.
— Capaj
40

Ce plus gros problème que je vois avec graphQL ie si vous utilisez avec une base de données relationnelle est avec les jointures .

  1. Le fait que vous puissiez autoriser / interdire quelques champs rend les jointures non triviales (pas simples). Ce qui conduit à des requêtes supplémentaires.

  2. Les requêtes imbriquées dans graphql conduisent également à des requêtes circulaires et peuvent planter le serveur . Des précautions supplémentaires doivent être prises.

  3. La limitation du débit des appels devient difficile car l'utilisateur peut désormais lancer plusieurs requêtes en un seul appel.

CONSEIL : utilisez le chargeur de données de Facebook pour réduire le nombre de requêtes en cas de javascript / node

— aWebDeveloper
source
1. En quoi les champs sélectionnés sont-ils pertinents pour rejoindre les opérations? 2. Pas si vous utilisez un chargeur de données. 3. Vous pouvez analyser et attribuer costà la demande. Ce n'est pas non plus un problème si vous utilisez des requêtes prédéfinies, où le client envoie uniquement l'ID.
— zoran404
1
d'accord avec 2. Avec 3 son peu de travail supplémentaire et plus important encore, les personnes doivent être conscientes.
— aWebDeveloper
1
2. Ce n'est plus vrai car vous pouvez utiliser de nombreux outils pour protéger votre serveur. Par exemple un lien: howtographql.com/advanced/4-security Timeouts , limite de complexité et de profondeur. Donc, c'est la même chose que vous dites que votre REST sera possible pour DDoS si vous n'utilisez pas de limiteur de débit. Les choses ont changé
— Yevhenii Herasymchuk
point 2 mis à jour
— aWebDeveloper
14

Cela va de mieux en mieux chaque année, et comme pour le moment, la communauté de GraphQL s'agrandit, et par conséquent, il y a beaucoup plus de solutions à beaucoup de problèmes qui ont été mis en évidence dans d'autres réponses auparavant. Mais pour admettre ce qui empêche encore les entreprises de consacrer toutes leurs ressources à GraphQL, j'aimerais énumérer quelques problèmes et solutions suivis de ceux non résolus.

  • Cache au niveau du réseau - comme Bruno l'a dit, il s'agit de requêtes persistantes et bien sûr, vous pouvez mettre en cache sur un client et personne ne vous empêche d'utiliser la mise en cache au niveau de la base de données ou même Redis. Mais bien sûr, comme GraphQL n'a qu'un seul point de terminaison et chaque requête est différente, il est beaucoup plus compliqué de faire ce type de mise en cache qu'avec REST.
  • Les requêtes imbriquées dans GraphQL conduisent à des requêtes circulaires et peuvent planter le serveur - ce n'est plus un problème avec une grande variété de solutions. Certains d'entre eux sont répertoriés ici
  • Manipulation File Upload - nous avons déjà beaucoup de solutions pour elle

Mais il y a quelques autres cas qui peuvent être considérés comme des inconvénients:

  • excès standard (je veux dire par là, pour la création, par exemple, d'une nouvelle requête, vous devez définir le schéma, le résolveur et à l'intérieur du résolveur pour dire explicitement à GraphQL comment résoudre vos données et champs à l'intérieur, du côté client, créez une requête avec exactement des champs liés à ces données)
  • gestion des erreurs - je dois dire que c'est plus lié à la comparaison avec REST. C'est possible ici avec apollo mais en même temps c'est beaucoup plus compliqué que dans REST
  • authentification et d' autorisation - mais comme jeai ditcommunauté augmente avecvitesse exceptionnelle et il y a déjà deux des solutions pour atteindre cet objectif.

Pour résumer, GraphQL n'est qu'un outil pour des objectifs spécifiques et ce n'est certainement pas une solution miracle à tous les problèmes et bien sûr pas un remplacement pour REST.

— Yevhenii Herasymchuk
source
4

C'est vraiment génial d'avoir un seul point de terminaison et d'exposer toutes les données. Je trouve ci-dessous les points à considérer pour GraphQL:

  1. La mise en œuvre du téléchargement / chargement de fichiers devient délicate (la conversion en chaîne n'est peut-être pas la meilleure option pour les fichiers volumineux)
  2. Beaucoup de code passe-partout et de schéma à la fois au frontend et au backend.
  3. Suivez et supportez la pagination fournie dans la spécification GraphQL.
  4. Autoriser l'ordre personnalisé et la logique de hiérarchisation pour l'ordre des champs. Exemple si nous récupérons les données des utilisateurs et les groupes et rôles associés. Un utilisateur peut effectuer un tri multiple des données en fonction du nom d'utilisateur, du nom du groupe ou du nom du rôle.
  5. L'authentification et l'autorisation dépendraient du cadre principal.
  6. Assurez-vous que l'optimisation du backend et la prise en charge de la base de données pour lancer une seule requête pour chaque commande graphql peuvent devenir délicates.

En outre, il convient de considérer les avantages après sa mise en œuvre:

  1. Très flexible pour prendre en charge de nouveaux éléments et mettre à jour le comportement existant.

  2. Facile à ajouter des conditions en utilisant des arguments et un ordre personnalisé une fois implémenté

  3. Utilisez beaucoup de filtres personnalisés et débarrassez-vous de toutes les actions qui doivent être créées, par exemple un utilisateur peut avoir un identifiant, un nom, etc. comme arguments et effectuer le filtrage. De plus, les filtres peuvent également être appliqués aux groupes des utilisateurs.

  4. Facilité de test de l'API en créant des fichiers contenant toutes les requêtes et mutations GraphQL.
  5. Les mutations sont simples et faciles à mettre en œuvre une fois le concept compris.
  6. Un moyen puissant pour récupérer plusieurs profondeurs de données.
  7. La prise en charge de l'interface utilisateur Voyager et GraphiQL ou de Playground facilite la visualisation et l'utilisation.
  8. Facilité de documentation lors de la définition du schéma avec des méthodes de description valides.
— vCillusion
source
3

Je pense que graphql pour le moment doit faire partie de l'architecture du backend, pour le téléchargement de fichiers, vous utilisez toujours une API régulière

— user998548
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.