TypeScript , GraphQL e NestJS formam as partes centrais de nossa pilha na Dandy. Juntos, eles fornecem um ecossistema poderoso e um conjunto de ferramentas que nos permite agir rapidamente, mantendo um sistema robusto e confiável. Os principais recursos que eles fornecem para nós são:

• Segurança de ponta a ponta
• Clientes gerados automaticamente (para chamadas front -end e entre serviços) por meio do Graphql Code Generator
• Separação de interesses para nossos microsserviços via GraphQL Federation
• Verificações de esquema, rastreamento e métricas de integridade por meio do Apollo Studio

Para começar, vamos dar uma olhada no sistema a partir de três perspectivas: a geração de código que une os componentes perfeitamente, como as solicitações fluem em tempo de execução e como o código se parece da perspectiva de um desenvolvedor trabalhando em serviços e aplicativos dentro o sistema.

Geração de código

Este é o pipeline de geração de código, que opera em alguns estágios:

Passando por isso:

• Temos vários serviços de back-end e aplicativos React voltados para o usuário.
• Nossos serviços de back-end definem graphqltipos de objetos usando decoradores GraphQL da NestJS, além de resolvedores para lidar com consultas e mutações nesses objetos.
• Os serviços de back-end geram seus próprios esquemas GraphQL usando o recurso de geração de arquivo de esquema do NestJS .
• Nosso serviço Apollo Gateway consome esses esquemas e gera um esquema federado combinando-os, permitindo que os clientes enviem operações GraphQL a qualquer um de nossos serviços no mesmo terminal.
• Nossos pacotes de geração de cliente usam o graphql-codegenpacote e o esquema federado para gerar tipos de Typecript para todos os objetos em nosso esquema.
• graphql-codegené então usado para gerar tipos e código de tempo de execução para operações definidas dentro de .graphqlarquivos em nossos pacotes de cliente. Nosso pacote de cliente de front-end gera ganchos React usando Apollo Client, enquanto nosso pacote de cliente de back-end usa o graphql-operationspacote npm para gerar uma classe de cliente.

Há muita coisa acontecendo lá, mas as coisas são muito mais simples quando processamos solicitações em tempo de execução:

O principal aqui é que os aplicativos nunca precisam interagir diretamente com os serviços de back-end, nem entre os serviços de back-end - todos os aplicativos e serviços enviam consultas e mutações ao Gateway, que então as despacha de maneira adequada. É importante ressaltar que isso é verdadeiro mesmo se a solicitação exigir que os dados sejam compostos de vários serviços.

Código

Para encerrar, vamos dar um passo para trás na geração de código enquanto ampliamos para dar uma breve olhada em como o código real (desenvolvido e gerado) se parece na prática.

Como você deve se lembrar, tudo começa com classes e resolvedores definidos em nossos serviços de back-end:

A partir deles, geramos um esquema GraphQL incluindo:

Em seguida, compomos o esquema federado (que mescla os esquemas de nossos vários serviços), mas omitiremos isso aqui, pois nosso exemplo usa apenas um único tipo de objeto de um único serviço.

Em seguida, algum padrão é gerado para tornar o tipo de dados e a consulta utilizáveis ​​no front-end:

Que no final das contas se parece com:

O cliente de back-end e o uso são semelhantes, exceto que o código gerado aproveita o graphql-requestpacote agnóstico de ambiente em vez dos ganchos Apollo / React.

Conclusão

Este é um exemplo muito simples, mas, o mais importante, seria tão simples de usar se o tipo de dados e o resolvedor fossem muito mais complicados, ou mesmo se a consulta exigisse que os dados fossem montados a partir de vários serviços.

Em artigos futuros, entraremos em mais detalhes sobre algumas das tecnologias e técnicas interessantes que acabamos de ver aqui. Se houver algo sobre o qual você esteja especialmente interessado em saber mais, entre em contato conosco.