Em 2020 minha equipe e eu resolvemos migrar o sistema do Vigia de Preço, que, na época, utilizava um framework desenvolvido internamente (que, inclusive, sempre foi Open Source e está disponível em https://github.com/dekproject), para o NestJS. Hoje vou falar um pouco do motivo para tomar essa decisão de migrar milhares de linhas de código de um projeto enorme, com milhões de usuários, para uma tecnologia de terceiros.
Entenda a evolução
Nossa história começa em meados de 2012, quando comecei o estudo do então Node.js na versão 0. Na época o projeto ainda não tinha se popularizado, ainda tinha vários problemas e a comunidade estava dividida entre o projeto do Node.js e do IO.js, que foi um Hard Fork. Portanto os padrões de desenvolver em Node ainda estavam sendo criados e, diferente do PHP e do .Net, a forma de se escrever em JavaScript assíncrono tem suas dificuldades. Perceba, ainda não existia ES6, logo não existiam Async, classes, arrow functions ou linguagem funcional, entre outros. Nessa época, em que a tecnologia mais recente era Bootstrap com Jquery e o Angular 1 tinha pouco tempo de lançamento, era necessário criar métodos mais eficientes para desenvolver produtos derivados do Node.js.
A primeira versão do framework que foi utilizado para criar o Vigia foi criado em 2014 e tinha o nome de Organized. Utilizava conceitos de injeção de dependência semelhantes aos do Angular 1. À medida que os padrões do ES5 iam sendo implementados, o código também passava por atualização. Em 2017 iniciamos uma versão 2.0. Apelidado de Dek, esse framework foi utilizado até 2020, sendo o core de vários projetos ao longo do processo, até a versão 5 do Vigia. Porém, em longo prazo, a manutenibilidade do projeto começou a ser prejudicada, pois efetivamente tínhamos a necessidade de criar recursos usando o framework como base e realizar manutenções e atualizações no core da aplicação para adicionar features à medida do necessário. Como nunca tivemos a preocupação de criar uma documentação pública para o projeto, existia uma curva de aprendizado um pouco mais longa para novos colaboradores. Até aí não era tanto problema, já que seu uso é bem simples, mas, com o escopo muito amplo, a forma como se escreviam códigos baseados no Dek tornou o sistema muito complexo de dar manutenção, principalmente por que o projeto tinha muitos microserviços e interconexões e muitos dos erros ocorriam por falta de tipos bem definidos de dados entre esses serviços que originalmente se comunicavam por RabbitMQ e JSON.
E por que Nest.js?
Obviamente não me lembro com exatidão de todos os motivos da escolha, mas, logo de cara, não seria mais necessário a nossa equipe atualizar o framework, a documentação é muito bem escrita e utiliza TypeScript, além disso, o Nest possui suporte padrão para microserviços, testes e várias outros módulos importantes.
O que me chamou a atenção é a forma como são utilizado Decorators e Reflect de meta dados entre controladores, injeção de dependências. Particularmente acredito ser uma das melhores implementações do mercado atualmente para backend Node.js, mesmo sendo um pouco burocrático. Inclusive foi o framework que utilizei para implementar toda a API do jogo Tales Of Shadowland. Recomendo muito fazer a leitura da documentação e testar a solução.
Obs.: Utilizamos Nest.js para API e microserviços. Para frontend, usamos Vue.js com Nuxt.js, então cada um no seu quadrado. Particularmente gosto tanto da arquitetura do Nest que estou utilizando parcialmente os códigos em um projeto pessoal de conceito, chamado UCS.js. Criei até um post recente falando sobre, vou deixar fixado:
E você aí, já conhecia o Nest.js? O que acha dele? Neste post vou deixar os comentários abertos, para podermos ter essa discussão.
