• Autor: Rohan Luthra
• Editora: Benila Susan Jacob

Um obstáculo

Iniciamos um novo projeto há um ano no CloudSEK e mudamos nossa arquitetura de monolítica e orientada a serviços para uma arquitetura de microsserviço adequada. Com os microsserviços, cada serviço tinha seu próprio repositório e pipeline de CD CI conectados à nossa malha de serviços Kubernetes.

Tudo estava indo bem até que o número de serviços começou a aumentar, e então ficou difícil gerenciar a base de código. Havia tantos MRs (Merged Requests) quanto repositórios, vários CICDs para gerenciar, vários problemas de acesso e muita duplicação de código, o que levou a um maior esforço manual. Embora existissem pacotes npm comuns, atualizar esse pacote em todos os repositórios era um pesadelo para os engenheiros. Isso acabou se tornando um gargalo e começou a afetar a velocidade da equipe.

A solução

Embora devesse ter sido previsto em nossa abordagem de microsserviços, aprendemos com seus erros. O problema é apenas com a capacidade de manutenção, portanto, um monorepo resolveria o problema.

Coisas no mercado

Como a pilha de tecnologia é TS, tanto front-end quanto back-end, havia algumas estruturas a serem analisadas. A seguir estão as estruturas nas quais fizemos um POC antes de prosseguir:

• Turborepo
• Lerna
• Nx

Escolhemos o Nx, pois ele tinha recursos prontos para uso com suporte a ReactJS e NestJS. Além disso, tinha algumas vantagens sobre outras soluções, especificamente com os comandos de código “afetados”.

Configurando o NX

Com o Nx, é muito simples, basta instalar o nx-cli globalmente e começar a adicionar aplicativos.

$ npx create-nx-workspace —pm pnpm —interactive false —defaultBase main —name my-workspace

Como estamos usando o NestJS, vamos criar 2 aplicativos e 2 bibliotecas

# instalar o plugin NestJS
$ pnpm install -D @nrwl /nest # apps
$ pnx g @nrwl /nest:app test1
$ pnx g @nrwl /nest:app test1# libs
$ pnx g @nrwl /nest: lib lib1
$ pnx g @nrwl /nest:lib lib2# inicie os aplicativos
$ pnpm run start:all

A estrutura da pasta deve ter a seguinte aparência:

 

Vantagens de usar o Nx

Como manter um monorepo é muito trabalhoso devido ao excesso de código, o Nx fornece uma maneira de obter apenas alterações: Afetado

Demonstramos com um exemplo como ele foi usado em nosso benefício. Na configuração, criamos 2 aplicativos e 2 bibliotecas e acabamos de importar as bibliotecas desses aplicativos. Vamos ver o gráfico geral:

 

 

gráfico $ pnx

 

$ pnx afetado: graph —base=main

 

$ pnx afetado: graph —base=main

Comandos com Afetado

As mudanças são refletidas em ambos os aplicativos. Usando os afetados, não precisamos executar lints, testes, compilações e implantações para toda a base de código, mas apenas para as partes afetadas.

Cereja no topo

Como isso foi integrado em nosso CD de CI, pudemos instalar, testar, criar e implantar nossos serviços. Todos os nossos pipelines funcionaram somente para alterações de código afetadas.

 

Mas a melhor descoberta foi que o tamanho do contêiner do docker era quase metade da nossa versão anterior. O motivo é que as compilações Nx e NestJS são muito diferentes e o Nx faz uma compilação menor.

Nx Build —

Compilação do NestJS —

Conclusão

Ninguém pode saber tudo, todos nós estamos apenas aprendendo com nossos erros. E o Nx é um dos melhores frameworks monorepo disponíveis para TS/JS. Neste blog, mostrei como o Nx nos ajudou a criar uma estrutura melhor para manter nosso código e aprimorar nosso pipeline. Alguns dos principais benefícios que obtivemos ao migrar para o Nx —

• Mais fácil de manter nosso código — repositório único
• Configurações escaláveis de CICD
• Pipelines de CI/CD mais rápidos — já que as tarefas são executadas somente para o código afetado
• Compilações menores do docker
• Integração simples com NestJS e ReactJS, fácil migração

Outras notas importantes com NX

• Mudando para o pnpm ( diff ) ( referência ), pois o pnpm é 3 vezes mais rápido que o npm/yarn
• Pode fazer testes e2e com Jest e cypress
• Também podemos publicar nossas bibliotecas ou aplicativos (opcional)