A stack mais eficás para projetos médios e grandes

Eu to no mercado mais formal à uns 3 anos, mas tenho uma história muito longa com o freelancing, que por muito tempo foi minha escola. E ao longo do tempo percebi alguns padrões que funcionaram muito bem para mim e quero pincelar minha stack em projetos médios e grandes, principalmente pensando no ambiente puro e estrito de projetos de freelance, mas apesar deste foco maior, é perceptível o ganho disso por grandes empresas, lembrando que tais vantagens também vão influenciar em um projeto empresarial, vou também citar alternativas para empresas que possam ter um time dedicado, pois o orçamento vai contar muito na escolha das tecnologias.

Larga de enrolação...

Geralmente as variáveis mais importantes em uma decisão de stack são, velocidade de escrita (o tempo que levamos para escrever e desenvolver em si), tamanho (ou complexidade) do projeto, e por ultimo e não menos importante, facilidade de setup, subir as coisas sem necessidade de um profissional de SRE ou DevOps. Interessante notar que os prazos geralmente são curtos, e você tem que economizar energia e tentar balancear cada ferramenta.

Entenda que a forma de decisão é mais importante que a escolha em si, eu em particular, sou um engenheiro de software, trabalho quase 90% no backend, então minha realidade é diferente, mas a forma de escolha pode te trazer ao sucesso.

Primeiro, linguagem tem que ser de fácil setup, mas não podemos deixar de levar em consideração o objetivo final de um projeto, falando de backend especificamente, setup inicial é importante, mas se você escolher uma linguagem pouco performática em um projeto de médio ou grande porte (ou com pretensões de ser), pois depois pode doer muito na hora de pagar as contas de cloud no fim do mês, sem falar é claro daquele bom e velho moedor de memória que vai te custar umas dores de cabeça no futuro...

Backend

Linguagem de programação: Golang

Go é uma linguagem criada pelo google como uma linguagem de propósito geral, o que chama atenção no Go é sua incrível simplicidade, grande parte de tudo o que se precisa fazer está na lib padrão, além
de uma comunidade gigantesca com muitas libs open source internet à dentro.

Fora estas qualidades, o Go é recomendado para processamento em larga escala, a forma simplificada como funciona o paralelismo na linguagem permite uma aplicação performática e dinâmica sem perder
tempo de desenvolvimento, no fim temos um código um pouco mais limpo por algumas obrigatoriedades da linguagem e pelo seu design, mas muitas vezes verboso pela herança da programação estruturada da
Linguagem C.

Uma das principais vantagens do Go, é a facilidade de subida de uma aplicação Go, isso pq todo o binário compilado já contem tudo o que se necessita para rodar, o que nos exime do trabalho com
configuração de ambiente (mesmo em docker com coisas como instalação de libs internas no SO), isso facilida muito o uso da linguagem na web, pois vc pode compilar o binário uma vez subir para qualquer
ambiente e simplesmente rodar, claro que para isso você deve usar o Go sem a flag de CGO, que ativa a compatibilidade com libs escritas em C, e isso pode ser uma mão na roda para aplicações mais baixo
nível e aplicações de sistema.

Banco de dados: Postgres ou Mongo

Tenho uma tendência leve de usar MongoDB em projetos de freelance, facilita muito o desenvolvimento e agiliza para caramba a nossa vida, mas deve ser usado com cuidado, um Mongo guardando dados
transacionais ou de alguma forma dependentes é um terror para manter em um projeto. Durante meu tempo trabalhando na Gobacklog tive contato com um sistema de gestão financeira, quase que um App web
para planejamento financeiro no geral, previdencia, férias, patrimônio, contas e despesas, etc. E este sistema com muitos dados claramente relacionais, que precisavam de transações claras foi
construido em cima de um MongoDB, basicamente o projeto virou um inferno, o servidor desperdiçava várias queries para conseguir trazer alguns dados da base, a leitura era ruim e o modelo de dados
engessado, o que tornava a aplicação deveras pesada e ineficiente.

Por isso e outros motivos é sempre bom saber pelo menos um banco relacional (são quase todos parecidos, então não faz tanta diferença para agente), o meu favorito por enquanto é o Postgres, é robusto
e muito utilizados em aplicações de alta performance, e além disso tem uma licensa muito livre, o que facilita a adoção em qualquer projeto, seja empresarial, freelance ou pessoal. Mas nem tudo são
flores com um banco relacional em mãos, já tive muitos problemas de performance em queries no passado por mà configuração de bancos, as principais causas disso são falta de índices ou Views mal
projetadas. Em meu período na Riverdata eu tive o despraser de conhecer um MySQL tão lento que uma query levava de 30s a 1m, e onde não tínhamos permissão de modificar de maneira alguma, nem com
índices novos, nem com views novas. Tivemos que criar um minerador de dados que batia em um índice muito expecífico e pre-processar parte das operações da aplicação para conseguir salvar esses dados
em um banco auxiliar, para que não necessitassemos bater na base lenta deles. Isso tudo é quase lei e a maior parte dos desenvolvedores mais experientes já tiveram em contato com problemas parecidos.

Na minha avaliação tanto o Postgres, quanto o Mongo são bancos muito poderosos e úteis em situações diferentes, tenha ambos em seu arsenal.

Então, quando usar Mongo? E quando usar Postgres?

Tendo a pensar que se você vai ter uma base com dezenas de modelos de dados, com atributos e links muito bem definidos entre si, use um Postres, isso é basicamente o ponto fraco do Mongo, pois as
queries de agregação e modificação de output do mongo são muito mais complicadas de entender que uma simples query SQL, mas caso
você tenha uma aplicação que via de regra terá pouca escrita, muita leitura e com estruturas mais livres ou independentes, utilize um Mongo.

Front End

Não dá para fugir do JavaScript no front-end, ele está quase onipresente em grande parte das aplicações atualmente, mas temos como pelo menos fingir que não é JavaScript utilizando seu descendente
com tipagem estática, o TypeScript, um ou outro, não importa tanto já que compartilham das mesmas ferramentas e tem compatibilidade entre si, claro que se você tem uma aplicação com mais complexidade,
e com modelos de dados mais variádos aí eu indicaria fortemente o TypeScript, já que facilita muito a manutenção pela claresa da tipagem forte.

Web: React JS

O React JS hoje em dia é uma das bibliotecas mais utilizada no desenvolvimento front-end, ela é muito valorizada por milhares de empresas e profissionais na área, suas maiores vantagens são a
facilidade e velocidade com que você consegue subir uma aplicação, além é claro na facilidade com o qual ela funciona com gestão de estados da aplicação e uma ótima biblioteca e comunidade com os mais
variados componentes e callbacks. Quase todo componente que você precisar consegue com libs ou snipets de código na web, além de uma simplicidade e possibilidades interessantes na
escolha de frameworks de CSS para facilitar a estilização.

Mobile: React Native

Muito semelhante à seu parente mais próximo (o próprio React JS), tem todas as suas facilidades, só que no mundo da produção de aplicativos mobile muiltiplataforma (funciona tanto para IOS quanto para
Android). Claro que ele tem algumas particularidades muito exclusivas tanto pelo contexto de estar em um celular como também por limitações da linguagem, então a estilização e os componentes usados
podem variar um pouco e divergir do React JS, mas ambos são muito semelhantes, a ponto de conseguir com poucas modificações transformar um código feito para o React JS no Native.

Conclusão

É importante salientar que cada contexto pede sua tecnologia, ou ferramenta, mas acredito que se as pretensões são de uma aplicação de alta complexidade, de alto processamento de dados brutos, enfim,
aplicações de médio ou grande porte, esta stack vai ser quase que um encaixe perfeito: Golang, React, Postgres/Mongo.

Preparado tanto pra alto volume de dados quando para processamento massisso, além de uma simplicidade tanto no momento do desenvolvimento, quanto na manutenção da aplicação.

Link para o post original em plankiton.com