Architecture GraphQL et Microservice
J'essaie de comprendre où GraphQL est le plus approprié à utiliser dans une architecture Microservice.
Il existe un débat sur le fait de n’avoir qu’un seul schéma GraphQL qui fonctionne comme passerelle d’API, qui envoie la requête aux microservices ciblés et force leur réponse. Les microservices utiliseraient encore le protocole REST/Thrift pour la pensée.
Une autre approche consiste à utiliser plusieurs schémas GraphQL, un par microservice. Avoir un serveur API Gateway plus petit qui achemine la demande au microservice ciblé avec toutes les informations de la demande + la requête GraphQL.
1ère approche
Avoir 1 schéma GraphQL en tant que passerelle API aura un inconvénient: chaque fois que vous modifierez l'entrée/la sortie de votre contrat de microservice, vous devez modifier le schéma GraphQL en conséquence du côté de la passerelle API.
2ème approche
Si vous utilisez Multiple GraphQL Schema par microservices, utilisez une méthode car GraphQL applique une définition de schéma et le consommateur doit respecter les entrées/sorties fournies par le microservice.
Questions
Si vous trouvez que GraphQL est la bonne solution pour concevoir une architecture de microservice?
Comment concevriez-vous une passerelle API avec une implémentation possible de GraphQL?
Certainement l'approche # 1.
Lorsque vos clients communiquent avec plusieurs services GraphQL (comme dans l’approche n ° 2), le but d’utiliser GraphQL est tout à fait contraire: il consiste à fournir un schéma sur l’ensemble entier données d'application pour permettre de les récupérer en un seul aller-retour.
Avoir une architecture sans partage peut sembler raisonnable du point de vue de microservices, mais pour votre code côté client, il s'agit d'un cauchemar absolu, car chaque fois que vous en changez un de vos microservices, vous devez mettre à jour tous de vos clients. Vous allez certainement le regretter.
GraphQL et les microservices conviennent parfaitement, car GraphQL cache le fait que vous avez une architecture de microservice parmi les clients. Du point de vue du backend, vous souhaitez tout scinder en microservices, mais du point de vue du front-end, vous souhaitez que toutes vos données proviennent d'une seule API. Utiliser GraphQL est le meilleur moyen que je connaisse pour vous permettre de faire les deux. Il vous permet de scinder votre backend en microservices, tout en fournissant une API unique à toutes vos applications et en permettant des jointures de données à partir de différents services.
Si vous ne souhaitez pas utiliser REST pour vos microservices, vous pouvez bien sûr avoir chacun leur propre API GraphQL, mais vous devez toujours disposer d'une passerelle d'API. La raison pour laquelle les gens utilisent des passerelles d'API est de rendre plus facile la gestion des appels de microservices à partir d'applications clientes, et non pas parce que cela s'inscrit parfaitement dans le modèle de microservices.
Voir l'article ici , qui explique comment et pourquoi l'approche n ° 1 fonctionne mieux. Regardez également l'image ci-dessous tirée de l'article que j'ai mentionné: 
L'un des principaux avantages de tout derrière un seul point d'extrémité est que les données peuvent être acheminées plus efficacement que si chaque requête disposait de son propre service. Bien que ce soit la valeur souvent vantée de GraphQL, une réduction de la complexité et du fluage des services, la structure de données résultante permet également à la propriété des données d'être extrêmement bien définie et clairement délimitée.
L’adoption de GraphQL offre un autre avantage: elle permet d’affecter un contrôle plus important du processus de chargement des données. Étant donné que le processus des chargeurs de données se trouve dans son propre terminal, vous pouvez accepter la demande partiellement, totalement ou avec des avertissements, et ainsi contrôler de manière extrêmement granulaire la manière dont les données sont transférées.
L'article suivant explique très bien ces deux avantages, ainsi que d'autres: https://nordicapis.com/7-unique-benefits-of-using-graphql-in-microservices/
Pour l’approche n ° 2, c’est en fait ce que j’ai choisi, car c’est beaucoup plus facile que de maintenir manuellement la passerelle d’API agaçante. De cette façon, vous pouvez développer vos services indépendamment. Rendre la vie beaucoup plus facile: P
Il existe d'excellents outils pour combiner des schémas en un seul, par exemple. graphql-weaver et apollo graphql-tools , j'utilise graphql-weaver, il est facile à utiliser et fonctionne très bien.
À partir de la mi-2019, la solution pour la 1ère approche porte désormais le nom " Schema Federation " forgé par le Apollo (Auparavant, on appelait cela l’agrafage GraphQL). Ils proposent également les modules @apollo/federation et @apollo/gateway pour cela.
ADD: notez qu'avec la fédération de schémas, vous ne pouvez pas modifier le schéma au niveau de la passerelle. Donc, pour chaque bit dont vous avez besoin dans votre schéma, vous devez avoir un service séparé.
J'ai travaillé avec GraphQL et microservices
Sur la base de mon expérience, ce qui fonctionne pour moi est une combinaison des deux approches en fonction de la fonctionnalité/utilisation, je n’aurai jamais une seule passerelle comme dans l’approche 1 ... mais un graphe graphique pour chaque microservice en tant qu’approche 2.
Par exemple, sur la base de l'image de la réponse d'Enayat, ce que je ferais dans ce cas est d'avoir 3 passerelles de graphe (pas 5 comme dans l'image)
App (produit, panier, expédition, inventaire, nécessaire/lié à d'autres services)
Paiement
Utilisateur
De cette façon, vous devez accorder une attention particulière à la conception des données minimales nécessaires/liées exposées à partir des services dépendants, comme un jeton d'authentification, un ID utilisateur, un ID de paiement, le statut du paiement.
Dans mon expérience, par exemple, j'ai la passerelle "Utilisateur", dans GraphQL, j'ai les requêtes/mutations de l'utilisateur, se connecter, se connecter, se déconnecter, changer le mot de passe, récupérer l'e-mail, confirmer l'e-mail, supprimer le compte, modifier le profil, télécharger une photo , etc ... ce graphe à lui seul est assez grand !, il est séparé car à la fin, les autres services/passerelles ne se soucient que des informations résultantes, telles que l’utilisateur, le nom ou le jeton.
De cette façon, il est plus facile de ...
Mettez à l'échelle/arrêtez les différents nœuds de passerelles en fonction de leur utilisation. (Par exemple, les personnes ne modifient pas toujours leur profil ou ne paient pas ... mais les produits de recherche peuvent être utilisés plus fréquemment).
Une fois qu'une passerelle a mûri, grandit, son utilisation est connue ou vous avez plus de connaissances sur le domaine, vous pouvez identifier la partie du schéma qui pourrait posséder sa propre passerelle (... m'est arrivé avec un énorme schéma qui interagit avec les dépôts git , J'ai séparé la passerelle qui interagit avec un référentiel et j'ai constaté que la seule information nécessaire/liée était: le chemin du dossier et la branche attendue)
L’historique de vos référentiels est plus clair et vous pouvez avoir un référentiel/développeur/équipe dédié à une passerelle et à ses microservices impliqués.