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

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.

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

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.

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

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.

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.

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