J'ai travaillé avec GraphQL et des microservices
D'après 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 pas un graphql pour chaque microservice comme approche 2.
Par exemple sur la base de l'image de la réponse d'Enayat, ce que je ferais dans ce cas, c'est d'avoir 3 passerelles graphiques (pas 5 comme dans l'image)
Application (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 identifiant d'utilisateur, un identifiant de paiement, un statut de paiement.
Dans mon expérience par exemple, j'ai la passerelle "Utilisateur", dans ce 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 l'image , etc ... ce graphe en lui-même est assez volumineux !, il est séparé car à la fin les autres services / passerelles ne se soucient que des informations résultantes comme l'ID utilisateur, le nom ou le jeton.
Cette façon est plus facile de ...
Mettez à l'échelle / arrêtez les différents nœuds de passerelles en fonction de leur utilisation. (par exemple, les gens peuvent ne pas toujours modifier leur profil ou payer ... mais la recherche de produits peut être utilisée plus fréquemment).
Une fois qu'une passerelle mûrit, grandit, son utilisation est connue ou que vous avez plus d'expertise sur le domaine, vous pouvez identifier la partie du schéma qui pourrait avoir sa propre passerelle (... m'est arrivé avec un énorme schéma qui interagit avec les référentiels git , J'ai séparé la passerelle qui interagit avec un référentiel et j'ai vu que la seule entrée nécessaire / information 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.
METTRE À JOUR:
J'ai un cluster kubernetes en ligne qui utilise la même approche que je décris ici avec tous les backends utilisant GraphQL, tous open source, voici le référentiel principal:
https://github.com/vicjicaman/microservice-realm
Ceci est une mise à jour de ma réponse car je pense qu'il est préférable que la réponse / approche soit sauvegardée du code qui est en cours d'exécution et peut être consulté / révisé, j'espère que cela aide.