A Dor Real: Quando a Autonomia dos Times Começa a Quebrar o Usuário
Microfrontend foi vendido como a bala de prata da escala no frontend. Só que **dividir tela não divide problema**. A cada boundary criado, o usuário paga a conta: latência, inconsistência visual, navegação truncada. No papel é lindo; no navegador vira gambiarra com branding desalinhado, múltiplas cargas de framework e corrida de eventos que explodem quando alguém muda um detalhe no time vizinho.
Para piorar, testar a jornada inteira vira um inferno. Historinhas isoladas não salvam a experiência se o fluxo completo quebra, como todo dev já viu em um E2E que falha ‘porque o processo estava sem memória’ — um clássico do caos citado em discussões de produtores de sistemas distribuídos.
Como Corrigir o Caos: Reduza as Fronteiras e Unifique o Shell
A solução pragmática não é abandonar microfrontends — é **parar de desmontar o produto em pedaços desnecessários**. O que funciona na prática:
- Um Shell proprietário forte, responsável por roteamento, design system e orquestração.
- Módulos remotos apenas quando existe fronteira real de negócio.
- Contrato de integração padronizado para evitar improvisação entre times.
O foco volta para o usuário, não para a arquitetura.
Implementação de Sênior: Microfrontend Usável com Module Federation
Abaixo, um exemplo simples e funcional usando Webpack Module Federation para carregar um módulo remoto sem destruir a UX:
// webpack.config.js do Shell
module.exports = {
mode: 'production',
plugins: [
new ModuleFederationPlugin({
name: 'shell',
remotes: {
checkout: 'checkout@https://cdn.seudominio.com/checkout/remoteEntry.js'
},
shared: ['react', 'react-dom']
})
]
};// Shell carregando o módulo remoto
import React, { Suspense } from 'react';
const Checkout = React.lazy(() => import('checkout/App'));
export default function App() {
return (
<Suspense fallback={'Carregando...'}>
<Checkout />
</Suspense>
);
}Esse padrão reduz carregamentos duplicados, garante que o Shell controle a experiência e mantém o deploy independente quando faz sentido.
O Custo da Escolha: Microfrontend Não é Graça — É Dívida Técnica Parcelada
Optar por microfrontends significa assumir:
- Mais pipelines, mais deploys e mais pontos de falha.
- Design system duplicado se o Shell não centralizar.
- E2E mais caros e mais lentos.
- Dívida técnica crescente se cada time reinventar integração.
Escolher microfrontend sem contexto de negócio é só over-engineering disfarçado de inovação.
Direto das Trincheiras
- Evite mais de três domínios de microfrontend por página — acima disso vira colcha de retalhos.
- Shell forte sempre: roteamento + design system + telemetry são responsabilidades centrais.
- Antes de criar um novo microfrontend, pergunte: “Existe uma razão de negócio ou só estou tentando separar código por conveniência?”
Fontes consultadas
Compreendendo e implementando microfrontends em AWS, Aplicação do estilo arquitetural microfrontend – Marcelo Colla
Obrigado por acompanhar essa reflexão até o fim!
Espero que esses pontos ajudem você a tomar decisões mais lúcidas no seu próximo projeto. Não deixe de conferir outros artigos aqui no blog, onde descasquemos outros hypes da nossa área.
Valeu e até a próxima! 😉
