GraphQL et Architecture Microservice
J'essaie de comprendre où GraphQL est le plus approprié à utiliser dans une architecture de Microservice.
Il y a un débat sur le fait d'avoir seulement 1 Schéma GraphQL qui fonctionne comme passerelle API proxy la demande aux microservices ciblés et forcer leur réponse. Les Microservices utiliseraient toujours le protocole REST / Thrift pour la pensée de communication.
Une autre approche consiste plutôt à avoir plusieurs schémas GraphQL un par microservice. Avoir un serveur de passerelle API plus petit qui acheminez la requête vers le microservice ciblé avec toutes les informations de la requête + la requête GraphQL.
1ère Approche
Avoir 1 Schéma GraphQL en tant que passerelle API aura un inconvénient où chaque fois que vous modifiez votre entrée / sortie de contrat microservice, nous devons changer le schéma GraphQL en conséquence du côté de la passerelle API.
2ème Approche
Si vous utilisez plusieurs schémas GraphQL par microservices, cela a du sens car GraphQL applique une définition de schéma, et le consommateur devra respecter les entrées / sorties fournies par le microservice.
Questions
Où trouvez-vous GraphQL la solution idéale pour concevoir une architecture microservice?
Comment concevriez-vous une passerelle API avec une implémentation possible de GraphQL?
5 réponses
Certainement approche #1.
Le fait que vos clients parlent à plusieurs services GraphQL (comme dans l'approche #2) va entièrement à l'encontre du but d'utiliser GraphQL en premier lieu, qui est de fournir un schéma sur vos données d'application entières pour permettre de les récupérer en un seul aller-retour.
Avoir une architecture shared nothing peut sembler raisonnable du point de vue des microservices, mais pour votre code côté client, c'est un cauchemar absolu, car chaque fois que vous changer un de vos microservices, vous devez mettre à jour Tous {[10] } de vos clients. Vous allez certainement le regretter.
GraphQL et microservices sont un ajustement parfait, car GraphQL cache le fait que vous avez une architecture de microservices des clients. Du point de vue du backend, vous voulez tout diviser en microservices, mais du point de vue du frontend, vous souhaitez que toutes vos données proviennent d'une seule API. L'utilisation de GraphQL est la meilleure façon que je connaisse qui vous permet de faire les deux. Il vous permet de diviser votre backend en microservices, tout en fournissant une seule API à toutes vos applications et en autorisant les jointures entre les données de différents services.
Si vous ne voulez pas utiliser REST pour vos microservices, vous pouvez bien sûr avoir chacun d'eux sa propre API GraphQL, mais vous devriez toujours avoir une passerelle API. La raison pour laquelle les gens utilisent des passerelles D'API est de rendre plus facile à gérer l'appel de microservices à partir d'applications clientes, non pas parce qu'il s'intègre bien dans les microservices modèle.
Voir l'article ici , qui dit comment et pourquoi l'approche #1 fonctionne mieux. Regardez également l'image ci dessous tirée de l'article que j'ai mentionné:
L'un des principaux avantages d'avoir tout derrière un seul point de terminaison est que les données peuvent être acheminées plus efficacement que si chaque requête avait son propre service. Bien que ce soit la valeur souvent vantée de GraphQL, une réduction de la complexité et du fluage du service, la structure de données résultante permet également à la propriété des données d'être extrêmement bien défini et clairement délimitées.
Un autre avantage de L'adoption de GraphQL est le fait que vous pouvez fondamentalement affirmer un plus grand contrôle sur le processus de chargement des données. Parce que le processus pour les chargeurs de données va dans son propre point de terminaison, vous pouvez soit honorer la demande partiellement, entièrement ou avec des mises en garde, et ainsi contrôler de manière extrêmement granulaire comment les données sont transférées.
L'article suivant explique très bien ces deux avantages avec d'autres: https://nordicapis.com/7-unique-benefits-of-using-graphql-in-microservices/
Pour l'approche # 2, en fait c'est la façon dont je choisis, car c'est beaucoup plus facile que de maintenir manuellement la passerelle API ennuyeuse. De cette façon, vous pouvez développer vos services de manière indépendante. 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 graphql-tools d'apollo, j'utilise graphql-weaver, c'est facile à utiliser et fonctionne très bien.
Comme l'architecture microservice n'a pas de définition appropriée, il n'y a pas de modèle spécifique pour ce style mais, la plupart d'entre eux viendront avec peu de notables characteristics.In dans le cas de l'architecture microservices, chaque service peut être décomposé en petits composants individuels, qui peuvent être modifiés et déployés individuellement sans affecter l'intégrité de l'application. Cela signifie que vous pouvez simplement changer quelques services sans aller pour le redéploiement de l'application via la coutume microservices développement d'applications.
En savoir plus sur les microservices, je pense que GraphQL pourrait fonctionner parfaitement dans l'architecture sans serveur aussi. Je n'utilise pas GraphQL mais j'ai mon propre projet similaire. Je l'utilise comme un agrégateur {[2] } qui invoque et concentre de nombreuses fonctions en un seul résultat. Je pense que vous pourriez appliquer le même modèle pour GraphQL.