Se você quer entender como aplicar a arquitetura de Micro Frontends em um projeto real, esse conteúdo é pra você.

A ideia aqui é simular a interface visual do Spotify, quebrando a aplicação em domínios funcionais, como se cada parte fosse responsabilidade de squads com missões bem definidas, seguindo o modelo organizacional de times autônomos:

🎯 Domínios Funcionais do Projeto

🎵 Listening Experience

Responsável pela área do player e controles de reprodução

📚 Library & Collections

Cuida das playlists, álbuns e conteúdo salvo

🔍 Content Discovery

Gerencia busca, recomendações e sugestões personalizadas

🧭 Navigation & Shell

Define a estrutura da interface, roteamento e layout principal

🧭 Etapa 1 — Orquestração: O Coração da Arquitetura

Mas antes de sair separando tudo em micro frontends, precisamos definir a base de como eles vão trabalhar em conjunto.

E é aí que entra a primeira etapa do nosso 📍Roadmap de Micro Frontends: Orquestração — o coração da arquitetura.

O que estamos realmente decidindo?

Quando falamos de orquestração, não estamos só escolhendo uma ferramenta ou estrutura de pastas. Estamos definindo decisões arquiteturais e de produto que terão impacto direto em:

• Escalabilidade da plataforma
• Autonomia dos times
• Governança de deploy
• Experiência do usuário
• Velocidade de entrega

Perguntas Fundamentais:

• Como os MFEs são organizados?
• Como as equipes vão trabalhar?
• Quem cuida do quê?
• Como as rotas se conectam?
• O que acontece se algo falhar?

Esse é o momento onde arquitetura e produto se alinham de verdade. Porque mesmo que cada MFE seja independente, o usuário precisa viver uma experiência única e integrada. E é a orquestração que garante que tudo funcione como uma plataforma — e não como um amontoado de aplicações desconectadas.

📦 1. Monorepo, Multi-repo ou Híbrido?

Essa decisão molda o modelo de colaboração entre times.

🔹 Monorepo

Tudo num único repositório.

✅ Quando usar:

• Equipe única ou pequena
• Ciclo de vida semelhante entre os MFEs
• Precisa de integração contínua e controle mais rígido

❌ Quando evitar:

• Vários times com níveis diferentes de maturidade
• Desejo por deploys independentes

🔹 Multi-repo

Cada MFE tem seu próprio repositório.

✅ Quando usar:

• Squads autônomos
• Produtos com roadmap separado
• Deploy sob controle de cada time

❌ Quando evitar:

• Projetos iniciais ou times com pouca integração entre si

🔹 Híbrido

Um mix: shared libs em monorepo, MFEs separados.

✅ Quando usar:

• Você precisa de consistência no Design System e utilitários
• Quer permitir liberdade nos MFEs, sem sacrificar padronização

Nossa escolha: Multi-repo, simulando uma organização com produtos distintos, gerenciados por times autônomos, mas com responsabilidades bem definidas.

🛠️ 2. Ferramenta de Orquestração: Quem Conecta Tudo?

Orquestração também envolve escolher a tecnologia que une tudo na tela.

Aqui, entramos na parte técnica da arquitetura: o shell, o carregamento dos MFEs, o gerenciamento do ciclo de vida e o fallback em caso de erro.

As opções avaliadas:

🔸 Single-SPA

• Agnóstico de framework
• Controle total do ciclo de vida de cada MFE
• Orquestração centralizada
• Ideal pra criar um shell que carrega e descarrega apps conforme a rota

🔸 Module Federation

• Compartilha código entre apps em tempo de execução
• Perfeito para Design System ou lib compartilhada
• Não cuida de rotas, nem orquestra MFEs diretamente

🔸 bit.dev / Zephyr Cloud

• bit.dev é ótimo para compartilhamento de componentes
• Zephyr Cloud é mais enterprise, com custos e curva de aprendizado mais altos

Nossa escolha: Single-SPA, porque:

• Precisamos de controle sobre o carregamento dos MFEs
• Queremos simular uma orquestração real com shell + apps
• É flexível, bem documentado e didático para quem está aprendendo

🌐 3. Roteamento Federado: Como Manter a Navegação Fluida?

Separar a aplicação em MFEs não pode quebrar a experiência de navegação. Por isso, precisamos decidir como será o roteamento entre e dentro dos MFEs.

Padrões que avaliamos:

📍 Roteador no Shell

O shell define todas as rotas principais e decide qual MFE renderizar em cada caminho.

✅ Fácil de manter
✅ Ótimo para SEO
❌ MFEs têm pouca liberdade

🔁 Roteamento Cruzado

Um MFE pode redirecionar para outro (ex: busca redireciona para player).

✅ Dá mais fluidez à navegação
❌ Pode gerar acoplamento

🌿 Rotas Aninhadas por Domínio

Cada MFE tem suas rotas internas sob um path dedicado (Ex: /search, /library, /player/:id).

✅ Ótimo para clareza e organização
❌ Exige coordenação entre shell e MFE

⚠️ Fallbacks e Erros Isolados

Cada MFE precisa tratar seus próprios erros. Shell não deve cair por erro em um MFE específico.

✅ Aumenta a resiliência
✅ Evita tela branca geral em caso de falha

Nossa estratégia:

• Shell gerencia as rotas principais
• MFEs cuidam das subrotas internas
• Usaremos boundaries de erro e fallback visual para garantir robustez

🧱 Decisão Arquitetural Não é Só Código

Arquitetura define como os produtos evoluem. E isso precisa andar junto com os objetivos de produto:

• Se um time quer lançar uma nova funcionalidade sem esperar o outro, a arquitetura precisa permitir.
• Se a empresa quer medir separadamente cada feature, a arquitetura precisa suportar.
• Se a escala do projeto vai crescer, o código precisa vir preparado.

A orquestração é onde tudo começa. É onde alinhamos tecnologia, produto e times.

🤝 E Agora?

Essa foi a primeira etapa. Vamos seguir juntos, implementando cada parte do projeto de forma pública, aberta e prática.

Se você quer participar e aprender junto:

• 🔗 Grupo LinkedIn: https://www.linkedin.com/groups/10085589/
• 🔗 Discord: https://discord.gg/mVzYTF5q7C
• 🔗 GitHub: https://github.com/mfe-brasil
• 📬 Newsletter: https://www.linkedin.com/newsletters/mfe-brasil-7317243074475175936/

---

Este é o primeiro artigo de uma série prática sobre implementação de microfrontends. Para discussões técnicas, contribuições ou dúvidas sobre implementação, me encontre no LinkedIn ou GitHub.