Editorial Veraxr

Frontend Monolítico X Micro-Frontend

Micro-frontend não é bala de prata técnica: o principal ganho aparece em governança e autonomia entre múltiplas equipes.

Imagem de capa do artigo Frontend Monolítico X Micro-Frontend

Da onda de microserviços ao micro-frontend

Após a estabilização da tendência de uso de microserviços para APIs e a popularização das provedoras de cloud, surgiu uma nova pergunta no desenvolvimento: por que não quebrar também os frontends em partes?

Para chegar nesse objetivo, muitas equipes recorreram a técnicas improvisadas, como uso de iframe. Com o Module Federation no Webpack 5, o padrão ganhou tração por oferecer uma forma mais padronizada de construir MFEs e um Host capaz de renderizar esses módulos.

Micro-frontend faz sentido no seu projeto?

Analisando tecnicamente benchmarks e testes de stress em uma aplicação estática monolítica rodando em Nginx, normalmente é preciso algo próximo de 10 mil usuários simultâneos e 100 mil requisições por segundo para começar a degradar a arquitetura.

Em um projeto com características semelhantes, mas dividido em MFE no mesmo cenário, os sinais de degradação também começam a aparecer em parâmetros muito próximos.

Ou seja: em um cenário básico, o Nginx já entrega alta capacidade e a adoção de micro-frontend não costuma se justificar apenas por parâmetros técnicos de throughput.

Onde está o ganho real

O micro-frontend mostra seu maior valor quando existem múltiplas equipes, com projetos diferentes, que precisam centralizar experiência em um único produto.

A ideia é ter um Hub (Shell/Host) e permitir que cada equipe entregue seus MFEs para plugar funcionalidades sem conflito direto na mesma codebase.

Nesse contexto, o ganho é organizacional e de autonomia: times evoluem partes distintas com menos acoplamento e ciclos de entrega mais independentes.