Arquitetura GraphQL e Microservice

Estou tentando entender onde o GraphQL é mais adequado para uso em uma arquitetura de Microservice.

Há um debate sobre ter apenas um esquema do GraphQL que funciona como o API Gateway proxyizando a solicitação nos microsserviços direcionados e coagindo sua resposta. Os microsserviços ainda usariam o protocolo REST / Thrift para refletir sobre a comunicação.

Outra abordagem é ter vários esquemas GraphQL, um por microsserviço. Ter um servidor API Gateway menor que roteie a solicitação para o microsserviço de destino com todas as informações da solicitação + a consulta GraphQL.

1ª Abordagem

Ter um esquema do GraphQL como um gateway de API terá uma desvantagem: sempre que você altera a entrada / saída do contrato de microsserviço, é necessário alterar o esquema do GraphQL de acordo no lado do gateway da API.

2ª Abordagem

Se estiver usando o Esquema Múltiplo do GraphQL por microsserviços, faça sentido porque o GraphQL impõe uma definição de esquema, e o consumidor precisará respeitar a entrada / saída fornecida pelo microsserviço.

Questões

• Qual o GraphQL ideal para o projeto de arquitetura de microsserviço?

• Como você projetaria um API Gateway com uma possível implementação do GraphQL?

Definitivamente abordagem # 1.

Fazer com que seus clientes conversem com vários serviços GraphQL (como na abordagem nº 2) derrota completamente o propósito de usar o GraphQL em primeiro lugar, que é fornecer um esquema para todo o seu dados do aplicativo para permitir a busca em uma única viagem de ida e volta.

Ter uma arquitetura de nada compartilhado pode parecer razoável da perspectiva dos microsserviços, mas para o código do lado do cliente é um pesadelo absoluto, porque toda vez que você altera um dos microsserviços, é necessário atualizar todos seus clientes. Você definitivamente vai se arrepender disso.

O GraphQL e os microsserviços são um ajuste perfeito, porque o GraphQL oculta o fato de você ter uma arquitetura de microsserviço dos clientes. De uma perspectiva de back-end, você deseja dividir tudo em microsserviços, mas, de uma perspectiva de front-end, você deseja que todos os seus dados venham de uma única API. Usar o GraphQL é a melhor maneira que conheço que permite fazer as duas coisas. Permite dividir seu back-end em microsserviços, ao mesmo tempo em que fornece uma única API para todos os seus aplicativos e permite unir dados de diferentes serviços.

Se você não deseja usar o REST para seus microsserviços, é claro que cada um deles pode ter sua própria API GraphQL, mas ainda deve ter um gateway de API. O motivo pelo qual as pessoas usam gateways de API é tornar mais gerenciável a chamada de microsserviços a partir de aplicativos clientes, não porque ele se encaixa bem no padrão de microsserviços.

Veja o artigo aqui , que diz como e por que a abordagem nº 1 funciona melhor. Veja também a imagem abaixo, tirada do artigo que mencionei:

Um dos principais benefícios de ter tudo por trás de um único ponto de extremidade é que os dados podem ser roteados com mais eficiência do que se cada solicitação tivesse seu próprio serviço. Embora esse seja o valor frequentemente elogiado do GraphQL, uma redução na complexidade e na fluência do serviço, a estrutura de dados resultante também permite que a propriedade dos dados seja extremamente bem definida e claramente delineada.

Outro benefício da adoção do GraphQL é o fato de que você pode fundamentalmente afirmar maior controle sobre o processo de carregamento de dados. Como o processo para carregadores de dados entra em seu próprio terminal, é possível atender a solicitação parcialmente, totalmente ou com advertências e, assim, controlar de maneira extremamente granular a forma como os dados são transferidos.

O artigo a seguir explica esses dois benefícios juntamente com outros muito bem: https://nordicapis.com/7-unique-benefits-of-using-graphql-in-microservices/

Para a abordagem nº 2, de fato, é assim que eu escolho, porque é muito mais fácil do que manter o gateway API irritante manualmente. Dessa forma, você pode desenvolver seus serviços de forma independente. Facilite a vida: P

Existem algumas ótimas ferramentas para combinar esquemas em uma, por exemplo, graphql-weaver e graphql-tools da apollo , estou usando graphql-weaver, é fácil de usar e funciona muito bem.

A partir de meados de 2019, a solução para a 1ª Abordagem passou a ter o nome " Federação de Esquema ", cunhada pelo pessoal da Apollo (anteriormente isso costumava ser chamado de costura do GraphQL). Eles também propõem os módulos @apollo/federatione@apollo/gateway para isso.

ADD: Observe que, com a Federação de esquema, você não pode modificar o esquema no nível do gateway. Portanto, para cada bit que você precisa em seu esquema, você precisa de um serviço separado.

A partir de 2019, a melhor maneira é escrever microsserviços que implementem a especificação do gateway Apollo e, em seguida, colar esses serviços usando um gateway seguindo a abordagem nº 1. A maneira mais rápida de construir o gateway é uma imagem do docker como esta. Em seguida, use o docker-compose para iniciar todos os serviços simultaneamente:

version: '3'

services:
    service1:
        build: service1
    service2:
        build: service2
    gateway:
        ports:
            - 80:80
        image: xmorse/apollo-federation-gateway
        environment: 
            - CACHE_MAX_AGE=5
            - "FORWARD_HEADERS=Authorization, X-Custom-Header" # default is Authorization, pass '' to reset
            - URL_0=http://service1
            - URL_1=http://service2

Da maneira como está sendo descrito nesta pergunta, acredito que o uso de um gateway de API personalizado como um serviço de orquestração pode fazer muito sentido para aplicativos corporativos complexos. O GraphQL pode ser uma boa opção de tecnologia para esse serviço de orquestração, pelo menos no que diz respeito à consulta. A vantagem da sua primeira abordagem (um esquema para todos os microsserviços) é a capacidade de agrupar os dados de vários microsserviços em uma única solicitação. Isso pode ou não ser muito importante, dependendo da sua situação. Se a GUI solicitar a renderização de dados de vários microsserviços ao mesmo tempo, essa abordagem poderá simplificar o código do cliente, de modo que uma única chamada possa retornar dados adequados para ligação de dados com os elementos da GUI de estruturas como Angular ou React. Essa vantagem não se aplica a mutações.

A desvantagem é o forte acoplamento entre as APIs de dados e o serviço de orquestração. As liberações não podem mais ser atômicas. Se você não introduzir alterações invertidas nas APIs de dados, isso poderá introduzir complexidade apenas ao reverter uma liberação. Por exemplo, se você estiver prestes a lançar novas versões de duas APIs de dados com as alterações correspondentes no serviço de orquestração e precisar reverter uma dessas versões, mas não a outra, será forçado a reverter as três de qualquer maneira.

Nesta comparação do GraphQL vs REST, você descobrirá que o GraphQL não é tão eficiente quanto as APIs RESTful, portanto, eu não recomendaria substituir o REST pelo GraphQL pelas APIs de dados.

Para a pergunta 1, a Intuit reconheceu o poder do GraphQL há alguns anos quando anunciou a mudança para o ecossistema da API One Intuit ( https://www.slideshare.net/IntuitDeveloper/building-the-next-generation-of-quickbooks-app-integrations -quickbooks-connect-2017 ). A Intuit optou por seguir a abordagem 1. A desvantagem mencionada na verdade impede que os desenvolvedores introduzam alterações de esquema que poderiam interromper os aplicativos clientes.

O GraphQL ajudou a melhorar a produtividade dos desenvolvedores de várias maneiras.

1. Ao projetar um novo microsserviço para um domínio, os engenheiros (backend / frontend / partes interessadas) concordam com um esquema para as entidades do domínio. Depois que o esquema é aprovado, ele é mesclado com o esquema de domínio principal (universal) e implantado no Gateway. Os engenheiros finais podem começar a codificar aplicativos clientes com esse esquema, enquanto os engenheiros de back-end implementam a funcionalidade. Ter um esquema universal significa que não há dois microsserviços com funcionalidade redundante.

2. O GraphQL ajudou os aplicativos clientes a se tornarem mais simples e rápidos. Deseja recuperar / atualizar dados para vários microsserviços? Todos os aplicativos clientes precisam acionar uma solicitação do GraphQL e a camada de abstração do API Gateway terá o cuidado de buscar e agrupar dados de várias fontes (microsserviços). Estruturas de código aberto como Apollo ( https://www.apollographql.com/ ) aceleraram o ritmo da adoção do GraphQL.

3. Com o dispositivo móvel sendo a primeira escolha para aplicativos modernos, é importante projetar para requisitos de largura de banda de dados mais baixos a partir do ponto zero. O GraphQL ajuda permitindo que aplicativos clientes solicitem apenas campos específicos.

Pergunta 2: Criamos uma camada de abstração personalizada no API Gateway que sabe qual parte do esquema pertence a qual serviço (provedor). Quando uma solicitação de consulta chega, a camada de abstração encaminha a solicitação aos serviços apropriados. Depois que o serviço subjacente retorna a resposta, a camada de abstração é responsável por retornar os campos solicitados.

No entanto, hoje existem várias plataformas (servidor Apollo, graphql-yoga etc.) que permitem criar uma camada de abstração do GraphQL em pouco tempo.

Eu tenho trabalhado com GraphQL e microsserviços

Com base na minha experiência, o que funciona para mim é uma combinação de ambas as abordagens, dependendo da funcionalidade / uso, nunca terei um único gateway como na abordagem 1 ... mas nether um graphql para cada microsserviço como abordagem 2.

Por exemplo, com base na imagem da resposta de Enayat, o que eu faria neste caso é ter 3 gateways de gráfico (não 5, como na imagem)

• Aplicativo (produto, carrinho, remessa, inventário, necessário / vinculado a outros serviços)

• Forma de pagamento

• Do utilizador

Dessa forma, você precisa dar atenção extra ao design dos dados mínimos necessários / vinculados expostos a partir dos serviços dependentes, como um token de autenticação, ID do usuário, ID do pagamento, Status do pagamento

Na minha experiência, por exemplo, eu tenho o gateway "Usuário", no GraphQL eu tenho consultas / mutações de usuário, login, login, logout, alteração de senha, recuperação de email, confirmação de email, exclusão de conta, exclusão de perfil, edição de perfil, upload de imagem , etc ... este gráfico por si só é bastante grande !, é separado porque no final os outros serviços / gateways se preocupam apenas com as informações resultantes, como ID do usuário, nome ou token.

Desta forma é mais fácil ...

• Escale / encerre os diferentes nós de gateways, dependendo do uso. (por exemplo, as pessoas nem sempre estão editando seu perfil ou pagando ... mas a pesquisa de produtos pode ser usada com mais frequência).

• Depois que um gateways amadurece, cresce, o uso é conhecido ou você tem mais experiência no domínio, é possível identificar qual é a parte do esquema que poderia ter seu próprio gateway (... aconteceu comigo com um esquema enorme que interage com os repositórios git , Separei o gateway que interage com um repositório e vi que a única entrada necessária / informações vinculadas era ... o caminho da pasta e a ramificação esperada)

• O histórico de seus repositórios é mais claro e você pode ter um repositório / desenvolvedor / equipe dedicado a um gateway e seus microsserviços envolvidos.

ATUALIZAR:

Eu tenho um cluster on-line do kubernetes que usa a mesma abordagem descrita aqui com todos os back-ends usando o GraphQL, todos de código aberto, eis o repositório principal: https://github.com/vicjicaman/microservice-realm

Esta é uma atualização da minha resposta, porque acho que é melhor se a resposta / abordagem tiver um código de backup em execução e puder ser consultado / revisado, espero que isso ajude.

Como a arquitetura de microsserviços não possui uma definição adequada, não há modelo específico para esse estilo, mas a maioria deles possui poucas características notáveis. No caso da arquitetura de microsserviços, cada serviço pode ser dividido em pequenos componentes individuais, que podem ser ajustado e implantado individualmente sem afetar a integridade do aplicativo. Isso significa que você pode simplesmente alterar alguns serviços sem precisar reimplementar o aplicativo por meio do desenvolvimento de aplicativos de microsserviços personalizados .

Mais sobre microsserviços, acho que o GraphQL também poderia funcionar perfeitamente em arquitetura sem servidor. Não uso o GraphQL, mas tenho meu próprio projeto semelhante . Eu o uso como um agregador que invoca e concentra muitas funções em um único resultado. Eu acho que você poderia aplicar o mesmo padrão para o GraphQL.