Nosso time está acostumado com a stack de tecnologia WINS (Windows, IIS, .NET, SQL Server).
Começamos o projeto ARDA (https://github.com/dxbrazil/arda) pensando no stack MEAN: MongoDB, Express.js, Angular, NodeJS. Queríamos colocar o Nginx na frente dos servidores Node, acessar um banco Mongo, guardar o código no GitHub, fazer o build no Jenkins e o deployment em containers.
Imaginando um cenário mais amplo, se tivéssemos um mapa das tecnologias, seria algo semelhante a esse mind map:
Criamos o ARDA querendo fazer tudo do jeito novo, mas no final usamos as tecnologias “Microsoft-ianas”:
- VSTS com Git
- HTML5 com páginas C# (Razor)
- jQuery
- CSS com pré-processador SASS
- ASP.NET Core
- .NET Core RC1
- Azure Active Directory
- Azure WebApp
- Azure SQL Database
De 2016 até hoje, tivemos algumas mudanças grandes:
- GitHub: migramos o código do VSTS para o GitHub público
- React: quase terminada a migração do código jQuery
- CSS: estamos brigando para tirar o SASS e sua bagunça
- Azure WebApp: ambiente apto a rodar no Docker, mas ainda usamos WebApps nos ambientes
- C# Razor: embora seja estranho usar HTML dinâmico, o Razor facilita na composição da tela (ex: menu)
- .NET Core: atualizado para a versão 1.1 e provavelmente vamos adicionar o .NET Framework no perfil de compilação
No atual momento, estamos bem satisfeitos com o ASP.NET Core (melhor que o ASP.NET 4.6) e com o banco de dados SQL Server.
Futura Migração para NodeJS e MongoDB
Não descarto uma possível migração da aplicação para NodeJS (Javascript) e MongoDB (NoSQL) desde que o propósito principal seja o aprendizado. Entretanto, é complicado trabalhar com uma linguagem não-tipada como o Javascript, assim como, com um repositório sem “schema de dados”, MongoDB.
Como avaliar o risco da mudanças de código antes de entrar em produção?
Aprendemos muito no projeto. Alguns exemplos que nos servem de lição:
- A mudança de jQuery para React está sendo bastante complexa, pois há diversas variáveis globais e callback em javascript espalhados no código-fonte. Durante a migração, adotamos o Typescript para nos ajudar a identificar erros durante a compilação. Porém, ainda há casos que não são resolvidos – por exemplo, as dependências entre o código Javascript e os elementos HTML DOM.
- A mudança do ASP.NET Core RC1 para RC2 foi traumática, assim como tivemos problemas na migração para as versões 1.0 e 1.1. Felizmente detectamos os erros porque o build quebrou e, por isso, o código nunca entrou em produção. Se estivéssemos rodando o NodeJS, estaria preocupado em migrar da versão v0.12 – v4 – v6 e depois mover para a produção sem a checagem de um compilador.
- Durante o upgrade da versão do Entity Framework, tivemos algumas mudanças de comportamento na forma como os dados eram escritos no banco de dados. Por conta disso, nosso sistema parou de funcionar e começou a disparar exceções porque nenhuma operação de INSERT funcionava. Voltamos a versão do aplicativo e tudo voltou a funcionar. A produção parou, mas nenhum dado foi gravado incorretamente. Porém, se fosse no MongoDB, essas informações estariam gravadas com os campos errados e só perceberíamos o erro dias/semanas/meses depois.
Conclusão
Nossa lição aprendida: se quisermos criar um projeto em NodeJS e MongoDB, será um pré-requisito ter testes unitários rodando no processo de Continuous Integration (CI).
Se não for possível cumprir a premissa, então é preferível usar uma linguagem tipada (C#/Java) com um banco relacional (SQL/MySql/Postgres).