Microfrontends na prática: escalando frontends grandes sem criar um monolito

Quando uma aplicação frontend começa a crescer, normalmente o primeiro problema não é performance.

Novas features, múltiplos desenvolvedores passam a trabalhar no mesmo código, deploys começam a ficar mais arriscados e, de repente, um projeto que parecia simples virou um grande monólito difícil de manter.

Foi justamente para resolver esse problema que surgiu o conceito de Microfrontends.

Neste artigo, vou explicar de forma simples:

• O que são microfrontends
• Quais problemas essa arquitetura resolve
• Benefícios e trade-offs
• Quando vale (ou não) usar

O problema dos frontends monolíticos

Imagine um sistema administrativo grande, tudo dentro de um único projeto React. Algo parecido com isso:

frontend-app/
 ├── src/
 │   ├── pages/
 │   ├── components/
 │   ├── services/
 │   ├── hooks/
 │   └── contexts/

No começo funciona bem.

Mas conforme o projeto cresce, começam os problemas:

• Deploy único
• Times dependentes
• Build cada vez maior

O que é arquitetura Microfrontend?

Microfrontend traz para o frontend a mesma ideia dos microservices no backend. Ao invés de uma única aplicação grande, dividimos o sistema em aplicações menores e independentes.

Exemplo:

Sistema Administrativo
├── Shell (Aplicação principal)
│
├── Microfrontend Customers
│     └── Gestão de clientes
│
├── Microfrontend Products
│     └── Gestão de produtos
│
└── Microfrontend Dashboard
      └── Métricas e indicadores

Cada parte é um projeto independente. Cada módulo pode:

• Ter seu próprio deploy
• Ser desenvolvido isoladamente
• Ser mantido por times diferentes
• Evoluir sem afetar outros módulos

Como funciona na prática

No meu caso, organizei usando Monorepo.

mfe-react/
├── apps/
│   ├── shell/
│   ├── mfe-customers/
│   ├── mfe-products/
│   └── mfe-dashboard/
│
├── packages/
│   └── shared-ui/
│
└── package.json

Shell

Responsável por orquestrar a aplicação. Ele carrega os MFEs dinamicamente, como um “container”. Ele não implementa as features. Ele apenas organiza os módulos.

Exemplo:

Shell
├── Header
├── Sidebar
└── Área dinâmica
       ├── Customers MFE
       ├── Products MFE
       └── Dashboard MFE

Mas como os microfrontends se comunicam?

Existem várias estratégias. A mais comum atualmente é usar Module Federation do Webpack ou Vite Federation (vite-plugin-federation).

Exemplo:

// Shell (vite.config.ts)
remotes: {
  customers: "http://localhost:5001/assets/remoteEntry.js",
  products: "http://localhost:5002/assets/remoteEntry.js",
  dashboard: "http://localhost:5003/assets/remoteEntry.js"
}

O shell baixa o código do microfrontend apenas quando necessário.

Microfrontends independentes

Cada MFE roda de forma isolada.

Exemplo:

localhost:5001 → Customers
localhost:5002 → Products
localhost:5003 → Dashboard

Cada um possui:

• Build próprio
• Deploy próprio
• Responsabilidade isolada

O pacote compartilhado (Shared UI)

O papel do pacote compartilhado é evitar duplicação e manter uma consistência visual.

Nele contém:

• Biblioteca de componentes
• Helpers
• Estilos globais

É importado por todos os MFEs assim:

import { Button } from "@shared/ui";

Benefícios dos Microfrontends

1. Deploy independente

Não é necessário publicar toda a aplicação para alterar apenas um módulo.

2. Times independentes

Cada equipe pode trabalhar em um domínio específico.

3. Isolamento de falhas

Se um microfrontend estiver fora do ar, o restante continua funcionando.

4. Menor acoplamento

Cada domínio evolui de forma independente. Menos dependência entre times.

5. Melhor manutenção

Aplicações menores são mais fáceis de entender e manter.

Mas nem tudo são vantagens

Apesar dos benefícios, existem desafios importantes:

• Compartilhamento de dependências
• Controle de versões
• Comunicação entre MFEs
• Consistência visual
• Build pipeline mais complexo

No meu caso, precisei resolver questões como:

• CSS não carregando no Shell
• Compartilhamento de componentes via workspace
• Build independente com Vite
• Tratamento de falha quando um MFE não está disponível

Quando usar Microfrontend?

Boa escolha quando:

✅ Aplicação muito grande ✅ Muitos times trabalhando simultaneamente ✅ Necessidade de deploy independente ✅ Produto tem múltiplos domínios claros ✅ Times precisam autonomia

Quando NÃO usar

Má escolha quando:

❌ Projeto pequeno ❌ Apenas 1 ou 2 desenvolvedores ❌ MVP inicial

Projeto que desenvolvi para estudo

Stack utilizada:

• React 18
• TypeScript
• Vite 5
• Module Federation (@originjs/vite-plugin-federation)
• TailwindCSS
• shadcn/ui
• Lucide React

A aplicação simula um painel administrativo dividido em domínios independentes.

Para mais detalhes, veja o repositório: https://github.com/fernandogatto/mfe-react

Conclusão

Microfrontend não é uma solução para todo projeto.

Mas quando a aplicação cresce e múltiplos times precisam trabalhar com autonomia, essa arquitetura pode facilitar e deixar sistemas grandes mais sustentáveis.