Como começar um projeto com microfrontends: guia prático com um clone do Spotify

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 decidindo?

Quando falamos de orquestração, além de escolher uma ferramenta ou estrutura de pastas, estamos tomando decisões de arquitetura e de produto que afetam diretamente:

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

Perguntas principais:

• 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 em que arquitetura e produto se alinham. 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

Arquitetura anda junto com produto

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 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.