GraphQL et Microservices

Question

Dans mon entreprise, nous avons opté pour une architecture de microservices pour un nouveau projet. Nous avons jeté un coup d'œil à GraphQL et avons réalisé son potentiel et ses avantages pour l'utiliser comme point de terminaison unique de notre API.

Ce sur quoi nous ne sommes pas d'accord, c'est la manière dont la communication doit être effectuée entre GraphQL et chaque microservice. Certains plaident pour REST, d'autres disent que nous devrions également avoir un endpoint graphQL pour chaque service.

Je me demandais quels étaient les avantages et les inconvénients de chacun. Par exemple, tout avoir en graphQL semble un peu redondant, car nous répliquerions des parties du schéma dans chaque service. D'un autre côté, nous utilisons GraphQL pour éviter certains pièges de REST. Nous avons peur que le fait d'avoir des points de terminaison REST annule les avantages obtenus avec GraphQL.

Quelqu'un a-t-il été confronté à un tel dilemme ? Aucun d'entre nous n'a d'expérience avec GraphQL, alors y a-t-il des avantages et des inconvénients évidents que nous pourrions manquer ?

Merci d'avance !

Answer 1

Grande question ! On dirait que vous vous demandez comment configurer votre architecture pour GraphQL et les microservices, et pourquoi.

Contexte

Je recommanderais d'utiliser GraphQL, car sa meilleure utilisation consiste à consolider les sources de données de manière propre et à exposer toutes ces données via une API standardisée. D'un autre côté, l'un des principaux problèmes liés à l'utilisation de microservices est qu'il est difficile de gérer toutes les fonctions différentes que vous pouvez avoir. Et à mesure que votre application se développe, la consolidation de toutes ces fonctions de microservices devient un problème majeur.

Les avantages de l'utilisation de ces technologies sont considérables puisque vous disposez désormais d'une passerelle API GraphQL qui vous permet d'accéder à vos microservices depuis votre client comme s'il s'agissait d'une seule application monolithique, mais vous bénéficiez également des nombreux avantages de l'utilisation des microservices du point de vue des performances et de l'efficacité.

Architecture

L'architecture que je recommande est donc d'avoir un proxy GraphQL en face de vos microservices et, dans vos résolveurs de requêtes et de mutations GraphQL, d'appeler la fonction dont vous avez besoin pour récupérer les données nécessaires.

Il n'y a pas vraiment de différence entre une passerelle GraphQL devant des microservices GraphQL ou une passerelle GraphQL devant des points d'extrémité REST, même si je dirais qu'il serait plus simple d'exposer les fonctions de vos microservices en tant que points d'extrémité REST puisque chaque fonction ne devrait théoriquement servir qu'un seul objectif. Dans ce cas, vous n'aurez pas besoin des frais généraux et des complexités supplémentaires de GraphQL, car il ne devrait pas y avoir trop de logique relationnelle en arrière-plan.

Si vous cherchez des fournisseurs de microservices, les meilleurs que j'ai vus sont les suivants AWS Lambda , Webtask , Fonctions Azure y Google Cloud Functions . Et vous pouvez utiliser Sans serveur comme moyen de gérer et de déployer ces fonctions de microservices.

Par exemple :

import request from 'request';

// GraphQL resolver to get authors
const resolverMap = {
  Query: {
    author(obj, args, context, info) {
      // GET request to fetch authors from my microservice
      return request.get('https://example.com/my-authors-microservice');
    },
  },
};

Service GraphQL

C'est un sujet que nous avons exploré à l'école. Aiguillage également, au cas où vous souhaiteriez vous appuyer sur un service pour vous aider à gérer ce flux de travail. Nous fournissons d'abord un service de backend GraphQL qui vous aide à vous familiariser avec GraphQL en quelques minutes, puis nous vous permettons d'ajouter vos propres microservices (c'est-à-dire une logique personnalisée) à votre API GraphQL sous la forme d'une composition de fonctions. Il s'agit essentiellement du système de webhook le plus avancé, qui vous offre la flexibilité et le contrôle sur la façon d'appeler vos microservices.

N'hésitez pas à rejoindre également le Rencontre GraphQL sans serveur à SF si vous êtes dans le coin :)

J'espère que cela vous aidera !

Answer 2

Mon entreprise utilise GraphQL en production depuis environ un an. La maintenance des schémas dans notre "API de plate-forme" et aussi dans nos microservices est devenue ardue. Les développeurs ne cessaient de nous demander pourquoi ils devaient faire un double travail et quel était l'avantage. D'autant plus que nous devions procéder à des examens approfondis du code pour modifier/mettre à jour le schéma GraphQL de production.

Lancement d'Apollo GraphQL suture du schéma qui a résolu la plupart des problèmes que nous avions. Essentiellement, les microservices individuels maintiennent chacun leur propre point de terminaison GraphQL, puis notre API de plate-forme Node.js les assemble tous ensemble. L'API qui en résulte est le rêve du développeur client, et les développeurs backend bénéficient du niveau d'autonomie sur leur code auquel ils sont habitués. Je vous recommande vivement d'essayer le schema stitching. Nous l'adoptons progressivement depuis quelques mois et c'est merveilleux.

En outre, en définissant nos sous-schémas, nous avons commencé à découpler certains microservices, en nous appuyant plutôt sur les extensions de données cousues pour combler les trous dans les objets. C'est comme la pièce manquante de DDD