Reescrevendo a API do balta.io
Há uns 4 anos atrás eu decidi implementar um esquema de assinaturas para que as pessoas pudessem pagar um valor acessível e ter acesso à todo o catálogo de cursos que realizava online. Na época escrevi a primeira API do André Baltieri Treinamentos, hoje balta.io, utilizando ASP.NET Web API e SQL Server.
Foi um doloroso processo, já que persistimos muito estado e temos poucas regras de negócio. Na época utilizei diferentes conceitos de OOP, fui obrigado a utilizar um ORM (EF no caso), o que tornou mais complicado o que era para ser simples.
Passado o tempo, precisei mudar o portal, atualizar diversas coisas e acabei por reescrever a API. Como já tinhamos o Frontend (Angular 1 + Bootstrap) separado do Backend, seria um processo bem tranquilo, mas eu precisava decidir qual tecnologia utilizar.
Na época o .NET Core estava bem instável ainda, e como eu utilizava Mac, a solução foi partir pro Node + Mongo, e que solução hein meu amigo?
Estes dois “carinhas” casaram com o cenário que temos no site, que é armazenar snapshots dos alunos (Perfil, Cursos, Progresso nas Aulas), já que não temos tantas regras de negócio.
O NoSQL foi o destaque aqui, permitindo a mutabilidade das informações, versionando e trabalhando com documentos, e junto ao Node, reduziu o trabalho de 2 meses para semanas.
Sem falar na “levesa” da API. Claro que um bom esquema de cache e um código bem escrito ajudam, mas desde aquela época, a API roda em uma das piores máquinas que o Azure oferece, veja você mesmo:
Sim, 1GB de armazenamento, infraestrutura compartilhada e por aí vai, isto segurando exatamente 1198 alunos!
Mudanças e Novos Desafios
Uma coisa que aprendemos com o Frontend foi a segmentar. Inicialmente havíamos implementado apenas um Frontend para tudo, e isto é uma loucura. Loucura que nos levou a segmentar tudo, chegando a ter mais de 5 aplicações diferentes, cada uma em uma URL.
Na API ainda não há esta necessidade, mas já é algo que estamos preparados caso necessário.
A comunicação e integração com uma plataforma de pagamentos também está sendo realizada, para fornecer um checkin em tempo real e completamente automatizado para o aluno, oferecendo Cartão de Crédito e Boleto como formas de pagamento.
Nós chegamos a conclusão, que nosso Frontend é bem mais complexo que nosso backend, tanto que começamos pelos protótipos e não pelo domínio (DDD), mas isto vou falar já já.
Linguagens
Talvez você fique surpreso em ler isto, mas novamente escolhemos o Node, mas desta vez com TypeScript (Não consigo mais escrever JS rsrsrs).
Embora o ASP.NET Core esteja até mais rápido que o Node, na minha humilde opinião o Node ainda casa melhor com NoSQL, afinal, é tudo JSON, não teria como ser diferente.
Em diversas situações, a necessidade de precisar criar um objeto para retornar na API, por demanda da tipagem do C#, acaba tomando tempo e irritando. Além disso, a indução do C# a OOP é clara, coisa que não precisamos neste cenário, afinal, não temos quase nenhuma regra de negócio.
Bancos de Dados
Alguma dúvida que seria NoSQL? Pois é, novamente estamos com o Mongo e não abrimos mão. Ele é rápido para escrita e leitura (Até mais do que precisamos), trabalha de forma conectada, e armazena estados (JSON), exatamente como precisamos.
Estamos em dúvida ainda sobre relatórios, se haverá a necessidade de um SQL Server para tal. Mas isto é algo que pensaremos mais adiante.
Microsserviços ou Serviços
No way! Nosso cenário não demanda nada disso. Ter vários serviços, cada um com um banco de dados, ter um API Gateway dentre outras demandas só tornariam nossa API mais cara, e talvez menos performática (Comunicação entre serviços).
Desta forma, teremos uma API apenas, conectada ao Mongo, servindo tudo que é ncessário para todos serem felizes :)
Domain Driven Design
No way! Nada de DDD, CQRS nem nada por aqui. Como comentamos, começamos nosso novo produto pelo Frontend, que é onde encontramos vários GAPs que precisavam serem corrigidos, nosso domínio é pequeno.
Aliás, você já parou para pensar que cada dia as APIs estão menores (Microsserviços) e deste modo, os domínios menores, ou inexistentes? Se uma API é tão pequena a ponto de possuir apenas um CRUD, qual a necessidade de utilizar DDD, CQRS e mais uma sopa de letrinhas? #DeixaNoController?
Resumo
Pois bem pessoal, passei por um tratamento de choque para me livrar de vários problemas que eu tinha, incluindo colocar a tecnologia na frente da solução.
As coisas muitas vezes são simples, e nós complicamos elas. Este produto novo que estamos fazendo, eu quero que seja parte de uma mudança, inclusive minha, focando menos em siglas e mais em soluções!
E aí o que você acha disso tudo?
