---
title: "Como Começar um Projeto com Microfrontends: Guia Prático com Spotify Clone"
slug: microfrontend-project-start
date: 2025-04-21
category: "Microfrontends"
tags: ["microfrontends", "single-spa", "architecture", "spotify-clone", "orchestration", "routing", "project-setup"]
readTime: "5 min"
excerpt: "Aprenda como aplicar microfrontends em um projeto real simulando o Spotify. Guia completo sobre orquestração, roteamento federado e decisões arquiteturais fundamentais."
url: https://eliseu.dev/blog/microfrontend-project-start
---

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/](https://www.linkedin.com/groups/10085589/)
- 🔗 **Discord**: [https://discord.gg/mVzYTF5q7C](https://discord.gg/mVzYTF5q7C)
- 🔗 **GitHub**: [https://github.com/mfe-brasil](https://github.com/mfe-brasil)
- 📬 **Newsletter**: [https://www.linkedin.com/newsletters/mfe-brasil-7317243074475175936/](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](https://linkedin.com/in/eliseusantos) ou [GitHub](https://github.com/EliseuSantos).*