Micro Frontends: "Overengineering" ou Inevitabilidade?
Desde que os Micro Frontends (MFE) apareceram pela primeira vez no ThoughtWorks Technology Radar em 2018, eles receberam tanto elogios quanto críticas extremas. No auge dos monorrepos com Turborepo em 2022-2023, perderam visibilidade, mas a partir de 2025 voltaram aos holofotes impulsionados por três ventos favoráveis: a estabilização do Module Federation 2.0, a adoção do Rspack em produção e o crescimento da diferença de produtividade entre times com agentes de IA. Este artigo apresenta uma visão geral da stack de tecnologia MFE em abril de 2026 e três casos de migração gradual de grandes empresas japonesas de finanças, SaaS e e-commerce.
Module Federation 2.0: A Conclusão da Segunda Geração
O Module Federation foi introduzido no Webpack 5 em 2020 como um mecanismo para carregar módulos dinamicamente a partir de remotes em tempo de execução. No 2.0, com contribuições do time do Rspack (ByteDance), foi estruturada uma nova API compatível tanto com Webpack quanto com Rspack. As melhorias são três. Primeiro, o sistema de plugins de runtime permite reescrever dinamicamente em tempo de execução a "lista de remotes" e as "versões de dependências compartilhadas", viabilizando A/B testing e entrega personalizada por atributo de usuário sem recarregamento de página. Segundo, o suporte a tipos — a versão 2.0 inclui `.d.ts` no container remoto, habilitando autocomplete na IDE. Terceiro, a extensão do Chrome DevTools "Module Federation Inspector" permite visualizar o status de carregamento em tempo real.
Webpack / Rspack / Vite: A Frente de Batalha das Ferramentas de Build
O Webpack 5 ainda é a primeira escolha para grandes projetos existentes pelo ecossistema robusto, apesar do seu posicionamento mais legado. O Rspack 1.x é um builder compatível com Webpack escrito em Rust, 5 a 10 vezes mais rápido, com suporte oficial ao Module Federation 2.0, tornando-se o padrão a partir de 2025. O Vite 6 tem suporte via plugin `@module-federation/vite`, mas a compatibilidade com HMR e resolução em runtime é ruim, sendo prudente tratá-lo como experimental no desenvolvimento. O Turbopack, em abril de 2026, ainda não tem suporte oficial ao Module Federation, então usar Webpack/Rspack é a opção prática para quem precisa do Module Federation.
Single-SPA e iframe: O Outro Caminho
O Single-SPA é uma abordagem onde um shell de aplicação gerencia o ciclo de vida de múltiplas SPAs, sendo ainda a melhor opção para organizações que precisam de coexistência heterogênea de frameworks (React + Vue + Angular). O lançamento da versão 7.0 em 2025 reduziu o overhead de inicialização em 40%. Na prática, o mais equilibrado é o híbrido de Module Federation + Single-SPA: o Single-SPA controla a montagem e o Module Federation gerencia as dependências compartilhadas. Essa configuração foi adotada pela Zalando, IKEA e pelos casos japoneses descritos a seguir.
Entrega no Edge e Invalidação de Cache
O maior desafio operacional do MFE é a "consistência de versões dos remotes". A melhor prática de 2026 é Immutable Assets + Manifest Indirection. Os chunks JS dos remotes recebem nomes de arquivo baseados no hash do conteúdo e são servidos com `max-age=31536000, immutable` para armazenamento de longo prazo, enquanto apenas o `mf-manifest.json` de entrada é entregue com cache de curta duração (`max-age=60`, `stale-while-revalidate=300`). O manifesto funciona como indireção para a troca de versão: ao atualizar a entrada, todos os hosts buscam a nova versão após o próximo TTL expirar.
Tanto no Cloudflare, Fastly quanto no CloudFront, tornou-se padrão gerenciar centralmente os manifestos no edge KV. O canário usa um campo `traffic_split` no manifesto, e o plugin de runtime do Module Federation 2.0 determina a proporção.
Caso 1: Divisão do "Frontend do Core Bancário" de um Megabanco
Um grande banco de internet banking tinha um aplicativo React monolítico (cerca de 2,4 milhões de LoC) e o dividiu em 7 MFEs por time. O gatilho foram problemas clássicos de inchaço: "as mudanças de um time bloqueavam o release de outros 6", "npm install levava 8 minutos" e "o build levava 22 minutos".
A configuração adotada foi Webpack + Module Federation 2.0 + Single-SPA. O host é um shell fino que contém apenas resumo de conta, navegação e autenticação, carregando dinamicamente 7 MFEs: "transferência", "fundos de investimento", "empréstimos", "cartão", "declaração fiscal", "seguros" e "atendimento".
A migração gradual foi planejada em 18 meses. Começou com o "Strangler Facade" — separar primeiro o shell e encapsular o monolito existente como um único MFE. Em seguida, as funcionalidades foram extraídas gradualmente do monolito para MFEs. Cada time passou a poder atualizar sua versão do React de forma independente; ao final da migração, as versões do React nos MFEs variavam do 18 ao 19.2.
Os resultados foram claros. O tempo de build caiu para uma média de 3 minutos por time (redução de 86% em relação aos 22 minutos). A frequência de deploy passou de uma vez por semana para uma média de 12 vezes por dia. O escopo de impacto de incidentes mudou de "parada total" para "apenas o MFE afetado". Como bônus na conformidade com auditorias regulatórias financeiras, foi possível manter evidências de deploy independentes por MFE.
Caso 2: Coexistência de Rspack + Vite em uma Empresa SaaS
Uma empresa de HR Tech SaaS opera o portal do administrador (Rspack) e o self-service do colaborador (Vite) com ferramentas de build diferentes. A diferença de requisitos — o portal do administrador é grande e precisa de compatibilidade com IE11 (requisito de clientes legados), enquanto o portal do colaborador é focado em mobile com prioridade à experiência do desenvolvedor — justificou a separação das ferramentas de build.
A integração via MFE cobre 4 funcionalidades: barra de navegação comum, central de notificações, busca e chat de ajuda. Cada uma vem de repositórios independentes, é construída com Rspack e carregada por ambos os portais via Module Federation 2.0. O lado Vite foi integrado como consumidor de remotes com o plugin `@module-federation/vite`.
A lição aprendida foi "minimize as dependências compartilhadas". Inicialmente, muitas libs como React, dayjs e Zustand foram adicionadas como `shared`, mas conflitos de singleton causaram 3 incidentes em produção. No final, reduziram para apenas 3: React, React-DOM e contexto de i18n. O bundle size aumentou, mas a estabilidade operacional melhorou drasticamente.
Caso 3: Migração para Entrega no Edge em uma Plataforma de E-commerce
Um SaaS de construção de lojas de grande e-commerce tem alta afinidade com MFE por sua natureza de oferecer frontends customizados por tenant. Em 2025, migrou para Rspack + Module Federation 2.0, e o Cloudflare Workers passou a gerar dinamicamente o manifesto MFE a partir do ID do tenant. "Lançamento gradual de novas funcionalidades apenas para clientes específicos" e "design temático exclusivo para feriados por tenant" tornaram-se possíveis sem deploy de engenharia. A armadilha foi o SEO, resolvido com resolução antecipada do manifesto no SSR e incorporação estática de dados estruturados. A taxa de indexação efetiva melhorou de 92% para 98%.
Devo Adotar MFE? Lista de Verificação para Decisão
A adoção ou não deve ser avaliada pelos seguintes critérios. Se 3 ou mais itens se aplicam, o MFE merece consideração séria: 5 ou mais times com ciclos de release independentes / tempo de build do monorrepo superior a 10 minutos / coexistência de frameworks ou versões diferentes / entrega de customização por tenant / necessidade de limitar o impacto de falhas por funcionalidade / necessidade de trilha de auditoria independente por funcionalidade. Por outro lado, se o time é de 1-2 pessoas, o build leva menos de 3 minutos e a simplicidade do carregamento inicial é a maior prioridade, o MFE é excessivo.
Conclusão: MFE na Era da "Redescoberta"
Impulsionados pela maturação do Module Federation 2.0, do Rspack, da entrega no edge e da autonomia dos times com agentes de IA, os MFEs em 2026 deixaram de ser "tecnologia para organizações pioneiras" e se tornaram "uma prática padrão para organizações com as condições certas". O mais importante não é adotar MFE como uma "solução universal", mas sim como uma prescrição concreta para as dores da organização e os requisitos do negócio. Como os 3 casos apresentados demonstram, em condições adequadas, o MFE traz melhorias de ordem de magnitude em tempo de build, frequência de release, escopo de impacto de falhas e liberdade de customização. Vale a pena revisitar a situação atual da organização antes de descartar o tema com um "MFE? Isso é coisa do passado" na próxima reunião de arquitetura.