Compromis GraphQL

Il est très facile de tomber amoureux de la technologie vendue par des professionnels du marketing. Cependant, le génie logiciel est difficile car il n’existe pas de solution unique pour tous les cas.

GraphQL est au centre des préoccupations depuis quelques années déjà. Avant d’ajouter cette belle abréviation à votre CV, j’aimerais partager des points résumés et des réflexions à ce sujet en fonction de l’expérience de production. Il y a du matériel frais et bon du célèbre Alex Xu que j’aimerais que vous regardiez en premier, donc je n’ai pas besoin d’entrer dans les détails ou de les répéter ici.

Bien que je soutiens pleinement les préoccupations mentionnées dans la vidéo, il y a quelques choses que je voudrais ajouter :

GraphQL ne va pas remplacer REST ou SOAP

C’est juste une autre façon de construire une API un peu différemment, mais certainement pas « la meilleure à cause de la nouvelle ». Je dirais même que c’est plus comme un SOAP pour des analyses de rentabilisation encore plus spécifiques. Ci-dessous, je donnerai plus de détails sur ce point en montrant des parallèles entre eux.

GraphQL est créé pour résoudre quelques problèmes spécifiques

Il couvre les cas où :

1. Vous faites des affaires là où la plupart des utilisateurs utilisent des « smartphones ». Ces utilisateurs changent fréquemment de réseau/FAI pendant leurs déplacements et peuvent travailler avec une connexion peu fiable ou de mauvaise qualité. Fondamentalement, GraphQL vous permet d’exécuter un moins grand nombre de requêtes de l’application mobile à l’API. Cependant, le diable est dans les détails.
2. Vous pouvez facilement intégrer toutes les données (que vous devez utiliser sur le client/l’interface utilisateur) dans un seul modèle de données (ou graphique de données). Cela peut être dû au fait que vous travaillez dans le Big Data ou qu’il existe des manières uniformes de représenter les informations provenant de diverses sources.

GraphQL vous permet d’optimiser le débit de votre équipe de développement en laissant votre équipe front-end réfléchir à ce qu’elle veut obtenir de l’API au lieu que votre équipe back-end propose son modèle de données ou de deviner quelle est l’API et le modèle de données les plus optimaux. Il n’est pas très efficace d’attendre le changement d’API (par les ingénieurs back-end) chaque fois que vous devez changer le côté de l’interface utilisateur. Ainsi, les développeurs d’interface utilisateur sont satisfaits car ils peuvent jouer avec les données et trouver différentes façons de les utiliser ou de les afficher. Cependant, sont-ils suffisamment informés pour le faire en toute sécurité ? Cet avantage a un coût.

GraphQL apporte des compromis

Cela nécessite cependant que vous soyez prêt pour certaines choses :

1. Vous devez générer le schéma de l’API, comme dans le cas de SOAP. Ce n’est pas nouveau et cela peut sembler normal lorsque vous êtes seul et responsable à la fois du backend et du frontend (construire un « Hello, World! »). Et ce n’est pas grave pendant que votre équipe tient dans une seule pièce (ou partage 2 pizzas) et peut facilement se parler très rapidement. Cependant, si votre équipe est nombreuse et/ou met fréquemment à jour les objets API, vous pouvez rapidement vous lasser de ce processus. Chaque fois que les ingénieurs back-end mettent à jour l’API et régénèrent le schéma, ils doivent se connecter avec certains pairs qui doivent récupérer leurs mises à jour. Ils doivent consacrer plus d’efforts à la création et à la maintenance d’étapes d’automatisation CI supplémentaires, ainsi qu’à une meilleure communication et plus fréquemment à l’aide de chats, de messagers, etc. De toute évidence, votre le processus de développement devient plus étroitement couplé et fragile. Il ne permet pas autant de flexibilité dans l’expérimentation que REST.
2. Il prend le contrôle de votre Performances des API hors des mains de votre équipe de développement back-end et entre les mains des clients (équipe de développement UI/client). Grâce à son typage fort, GraphQL permet des requêtes dites spécifiées par le client. Dans le pire des cas, cela conduit à un problème N+1. La flexibilité que GraphQL offre à l’équipe client s’accompagne de la possibilité d’effectuer des requêtes de base de données lentes de manière imprévisible. Bien sûr, cela peut être atténué par des tests manuels ou automatisés, mais il convient de garder à l’esprit. Et certainement, cela pourrait ne pas être acceptable dans certains cas.

De toute évidence, GraphQL réduit le nombre de cas d’utilisation qu’il résout et n’est pas une solution miracle. Vous devez évaluer les compromis mentionnés dans la vidéo et la liste ci-dessus avant de vous étonner des avantages qu’elle offre.