Um experimento sobre sair da zona de conforto

Trabalhar em um sistema sem um caminho bem definido faz o processo parecer um encaixe gradual de peças soltas, onde o aprendizado acontece tanto nos acertos quanto nos erros inevitáveis da construção.

Eu não lembro exatamente quando virou essa chave, mas teve um momento em que olhei para o meu portfólio e senti que ele não acompanhava mais o tipo de coisa que eu queria saber fazer.

Não era exatamente falta de projeto, mas falta de variedade técnica mesmo, como se tudo estivesse sempre girando das mesmas linguagens. E isso começou a me incomodar porque, principalmente olhando vagas, eu percebi que o que mais aparecia não era dominar uma linguagem específica, mas ter repertório em mais de uma linguagem e conseguir transitar entre diferentes contextos sem travar.

Foi daí que surgiu a ideia de reimplementar um projeto meu antigo, mas saindo da zona de conforto. Então segui pela linha de microserviços, porque ao invés de um sistema único, ele te força a lidar com mais linguagens, com comunicação entre containers, e principalmente a aceitar que você vai errar várias coisas pequenas antes de tudo funcionar como um conjunto.

Antes de começar, passei um tempo olhando stacks que aparecem com frequência em vagas. Acabei separando algumas combinações que, de certa forma, se complementam bem para esse tipo de experimento:

Escolhi uma API em Dart porque, apesar de eu já ter mexido bastante com Flutter, backend nele era algo que eu nunca tinha explorado
O Java com Spring Boot foi quase o oposto disso, porque eu já tinha uma base mínima, mas nunca tinha ido fundo em estrutura de projeto, dependências e camadas
O NestJS entrou porque eu sempre usei TypeScript de forma muito solta com Node e Express, e queria entender como isso se organizaria de um jeito mais estruturado
O Angular foi um exercício de aceitar uma forma diferente de pensar frontend, pois sempre estive muito mais próximo do React

A parte interessante disso tudo foi tentar manter alguma coerência. Eu comecei a desenhar o sistema como um conjunto de serviços que se comunicam, e isso me forçou a pensar em contratos desde o início, em como cada serviço iria expor suas responsabilidades e como eles não deveriam depender demais uns dos outros.

Em algum momento isso virou também um exercício de infraestrutura, porque não adianta separar em microserviços se você não consegue rodar isso localmente sem virar um caos. Então eu comecei a estruturar tudo com Docker, criando Dockerfiles para cada serviço, tentando padronizar o mínimo possível para conseguir subir o ambiente inteiro com mais de um container conversando entre si.

E aí entrou uma parte que eu não tinha tanta familiaridade antes, que foi justamente lidar com rede entre containers, portas, comunicação interna, variáveis de ambiente, e perceber que muitas vezes o problema não estava no código em si, mas em como as peças estavam tentando se encontrar.

Com isso eu fui montando um sistema que nunca teve a intenção de ser perfeito, mas que me levou a aprender coisas novas e ganhar experiência mesmo errando no caminho.