ASP.NET x NodeJS e MongoDB


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:

 

New Mind Map (3)

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).


Comments (0)

Skip to main content