Alguns meses atrás me deparei com a necessidade de refazer um projeto front-end do zero. Isso me levou a uma busca por padrões de projetos aplicados ao front-end - algo que, particularmente, não é tão fácil de encontrar quanto no back-end.
Depois de algum tempo estudando sobre monolitos, micro front-ends e monolitos modulares, cheguei a algumas reflexões que rascunho abaixo.
Micro front-end vs. Monolito Modular vs. Monolito
Uma das primeiras questões que veio à mente foi: qual dos modelos adotar? Para isso, considerei os pontos abaixo.
Micro front-end
Pros
Permite que módulos da aplicação sejam desenvolvidos e implantados de forma totalmente independente. Isso reduz acoplamento, facilita escalabilidade e permite que times diferentes evoluam partes distintas da aplicação no seu próprio ritmo. Também possibilita escalar recursos de forma isolada para apenas os serviços que precisam.
Contras
Em contrapartida, aumenta a complexidade da arquitetura. Requer mais infraestrutura, mais pipelines, mais pessoas para dar suporte e, consequentemente, maior custo de cloud. Também exige maturidade para lidar com versionamento, comunicação entre módulos e consistência visual.
Monolito
Pros
É um modelo clássico, simples de gerenciar e que costuma atender bem a maioria das necessidades. O código fica centralizado, o deploy é único e os custos — tanto de pessoal, quanto de infraestrutura — tendem a ser menores.
Contras
Com o tempo, pode se tornar uma base de código altamente acoplada e difícil de manter. À medida que a equipe cresce, o fluxo de trabalho paralelo tende a gerar conflitos e gargalos. Escalar o sistema geralmente exige aumentar recursos da máquina inteira, e não apenas da parte que realmente precisa.
Monolito Modular
O monolito modular traz um ponto de equilíbrio entre os dois extremos. Ele mantém um único projeto e um único deploy, mas organiza o código em módulos bem separados, com responsabilidades claras, limites explícitos e baixo acoplamento.
Dessa forma, múltiplas pessoas podem trabalhar em paralelo — desde que estejam em módulos distintos — sem o mesmo nível de conflito de um monolito comum. Além disso, caso algum módulo precise virar um serviço independente no futuro, o esforço de extração tende a ser muito menor do que em um monolito tradicional.
Mas existe um ponto crucial para que esses módulos façam sentido: DDD. E esse é um tema que vale um artigo próprio.
Top comments (0)