Existe-t-il des inconvénients à GraphQL?
Tous les articles sur GraphQL vous diront à quel point c'est merveilleux, mais y a-t-il des inconvénients ou des inconvénients? Je vous remercie.
Désavantages:
- Vous besoin d'apprendre comment configurer GraphQL. L'écosystème évolue encore rapidement, il faut donc suivre.
- 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 client -> 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 noeud final 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 REST endpoint
- Le serveur doit faire 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 est pas si difficile à apprendre
- Le code supplémentaire est seulement quelques Ko
- En définissant un schéma, vous allez éviter beaucoup de travail par la suite réparer les bugs et endurer les mises à jour velues
- Il y a beaucoup de gens qui passent à GraphQL donc il y a un écosystème riche en développement, avec un excellent outillage
- Lors de l'utilisation de requêtes persistantes en production (en remplaçant les requêtes GraphQL par un ID et des paramètres), vous envoyez réellement 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
J'ai trouvé quelques points importants problèmes pour ceux qui envisagent d'utiliser GraphQL , et jusqu'à présent, les points principaux sont les suivants:
Requête en profondeur indéfinie : GraphQL ne peut pas interroger en profondeur indéfinie. Par conséquent, si vous avez un arbre et souhaitez renvoyer une branche sans connaître la profondeur, vous faire de la pagination.
Structure de réponse spécifique : dans GraphQL, la réponse correspond à la forme de la requête. Par conséquent, si vous devez répondre dans une structure très spécifique, vous devrez ajoutez une couche de transformation pour remodeler la réponse.
Cache au niveau du réseau : en raison de la manière habituelle dont GraphQL est utilisé sur HTTP (A POST sur un seul noeud final) , le cache au niveau du réseau devient difficile.Le moyen de le résoudre consiste à utiliser les requêtes persistantes.
Gestion du téléchargement de fichiers : la spécification GraphQL n’a rien à voir avec le téléchargement de fichiers et les mutations n’acceptent pas les fichiers dans les arguments. Pour résoudre ce problème, vous pouvez télécharger des fichiers à l’aide d’autres types d’API (REST, par exemple) et transmettre l’URL du fichier téléchargé à la mutation GraphQL, ou injecter le fichier dans le contexte d’exécution afin que le fichier soit intégré aux fonctions de résolution.
Exécution imprévisible : La nature de GraphQL est que vous pouvez interroger en combinant tous les champs que vous voulez mais cette flexibilité n'est pas gratuite. Certaines préoccupations intéressantes, telles que les requêtes de performances et N + 1.
API super simples : si vous avez un service qui expose une API très simple, GraphQL ne fera qu'ajouter une complexité supplémentaire, donc un simple REST API peut être mieux.
Ce plus gros problème que je vois avec graphQL, c’est-à-dire si vous utilisez une base de données relationnelle, est avec jointures.
Le fait que vous puissiez autoriser/interdire quelques champs rend les jointures non triviales (pas simples). Ce qui conduit à des requêtes supplémentaires.
De plus, les requêtes imbriquées dans graphql conduisent à des requêtes circulaires et peuvent planter le serveur. Des précautions supplémentaires doivent être prises.
La limitation du débit devient difficile car l’utilisateur peut maintenant lancer plusieurs requêtes en un seul appel.
TIP : Utilisez le dataloader de Facebook pour réduire le nombre de requêtes en cas d'utilisation de javascript/node
Cela va de mieux en mieux chaque année, et pour l’instant, la communauté de GraphQL est en croissance et, par conséquent, il existe beaucoup plus de solutions à beaucoup de problèmes qui ont déjà été soulignés dans d’autres réponses précédentes. Mais pour admettre que ce qui empêche encore les entreprises de consacrer toutes leurs ressources à GraphQL, j'aimerais énumérer quelques problèmes et solutions suivis par des problèmes non résolus.
- Cache au niveau du réseau - as Bruno dit qu'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 de Redis. Mais bien sûr, GraphQL n’ayant qu’un seul point de terminaison et chaque requête étant différente, c’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 - plus un problème avec une grande variété de solutions. Certains d'entre eux sont listés ici
- Gestion du chargement de fichiers - nous avons déjà lots de solutions pour cela
Mais il y a quelques autres cas qui peuvent être considérés comme des inconvénients:
- excessivité de la plate-forme (par cela, je veux dire, pour créer par exemple une nouvelle requête, vous devez définir un schéma, un résolveur et dans le résolveur pour dire explicitement à GraphQL comment résoudre vos données et vos champs à l'intérieur, créez une requête côté client avec exactement les champs liés à ces données)
- traitement des erreurs - Je dois dire que c'est davantage 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 autorisation - mais comme je l'ai dit, la communauté augmente à une vitesse exceptionnelle et il y a déjàcoupleofsolutions pour cet objectif.
Pour résumer, GraphQL n’est qu’un outil pour des objectifs spécifiques et, à coup sûr, ce n’est pas une solution miracle à tous les problèmes et, bien sûr, ne remplace pas REST.
C'est vraiment génial d'avoir un seul terminal et d'exposer toutes les données. Je trouve ci-dessous des points à prendre en compte pour GraphQL:
- La mise en œuvre du téléchargement/téléchargement de fichiers devient une tâche délicate (la conversion en chaîne peut ne pas être la meilleure option pour les fichiers volumineux)
- Beaucoup de code standard et de schéma de schéma à la fois en amont et en aval.
- Suivez et supportez la pagination fournie dans la spécification GraphQL.
- Autoriser l'ordre personnalisé et la logique de hiérarchisation des priorités 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.
- L'authentification et l'autorisation dépendent du cadre principal.
- Assurez-vous que l'optimisation de l'interface et la prise en charge de la base de données permettant de déclencher une requête unique pour chaque commande graphql deviennent difficiles.
En outre, il convient de considérer les avantages après sa mise en œuvre:
- Très flexible pour prendre en charge de nouveaux éléments et mettre à jour le comportement existant.
Facile d'ajouter des conditions en utilisant des arguments et un ordre personnalisé une fois implémenté
Utilisez beaucoup de filtres personnalisés et supprimez toutes les actions à créer. Par exemple, un utilisateur peut avoir comme identifiant, nom, etc. comme argument et effectuer le filtrage. De plus, les filtres peuvent également être appliqués aux groupes des utilisateurs.
- Facilité de test API en créant des fichiers contenant toutes les requêtes et mutations GraphQL.
- Les mutations sont simples et faciles à mettre en œuvre une fois le concept compris.
- Un moyen puissant pour extraire plusieurs profondeurs de données.
- La prise en charge de Voyager et de GraphiQL UI ou Playground facilite la visualisation et l’utilisation.
- Facilité de documentation lors de la définition du schéma avec des méthodes de description valides.
Je pense que graphql pour le moment doit faire partie de l'architecture dorsale, pour le téléchargement de fichiers, vous devez toujours cliquer