---
title: "Planejando a Arquitetura de Microfrontends: Shell, Domínios e Estrutura Multi-Repo"
slug: microfrontend-architecture-planning
date: 2025-04-22
category: "Microfrontends"
tags: ["microfrontends", "single-spa", "architecture", "cloudflare", "biomejs", "design-system", "multi-repo"]
readTime: "4 min"
excerpt: "Guia completo para estruturar a arquitetura de microfrontends com Single-SPA, separação por domínios, padrões de código com BiomeJS e deploy com Cloudflare Pages."
url: https://eliseu.dev/blog/microfrontend-architecture-planning
---

Na publicação anterior mostramos como iniciamos um projeto com **Micro Frontends** na prática. Agora, chegou a hora de apresentar como vamos estruturar a arquitetura da plataforma, separar responsabilidades entre os times e iniciar a criação do nosso **Shell (orquestrador)** com single-spa.

Esta etapa é crucial: define as bases técnicas e organizacionais que permitirão escalar o produto com segurança e autonomia entre os times.

## 🤔 Por que Single-SPA?

O **single-spa** é uma das soluções mais robustas para orquestração de MFEs. Ele permite:

- ✅ **Carregar múltiplas aplicações frontend** em tempo de execução
- ✅ **Usar diferentes frameworks** na mesma interface (React, Vue, Angular, Svelte…)
- ✅ **Ter deploys isolados** e controle de versão por aplicação
- ✅ **Adotar uma estrutura** pensada para escalar

## 🧩 Entendendo os Conceitos Base

Antes de mostrar a estrutura, é importante entender o papel de cada parte:

### **Application**
Uma app completa que é registrada e ativada via rota

### **Parcel**
Módulo leve e independente, ideal para widgets reutilizáveis

### **Styleguide**
Biblioteca de UI (design system) compartilhada entre os MFEs

### **Core**
Orquestrador das applicações

## 🗂️ Estrutura por Domínio (Multi-Repo)

Nossa arquitetura será orientada a domínios, com cada aplicação em um repositório separado e com total autonomia para o time responsável. O padrão de nomenclatura será:

```
spotify-mfe-[nome]
```

### Veja como ficou nossa separação inicial:

- **🎵 spotify-mfe-listening** (React) - Player e controles de reprodução
- **📚 spotify-mfe-library** (Vue) - Playlists, álbuns e conteúdo salvo
- **🔍 spotify-mfe-discovery** (Angular) - Busca, recomendações e sugestões
- **🧭 spotify-mfe-shell-core** (Vanilla JS) - Orquestrador e navegação
- **🎨 spotify-mfe-design-system** (Multi-framework) - Design System compartilhado

> **✳️ Observação**: A escolha dos frameworks é apenas uma sugestão. Cada time poderá definir o stack que fizer mais sentido para seu domínio — inclusive padronizando tudo em React ou outro framework se preferirem. O mais importante é que a plataforma está preparada para dar suporte a essa flexibilidade.

## 🧰 Padrões de Código

Para garantir consistência no código entre todos os repositórios, adotamos como padrão o **BiomeJS** — uma alternativa moderna ao combo ESLint + Prettier:

- 🚀 **Rápido** (feito em Rust)
- 🧼 **Unifica lint e format** em uma única ferramenta
- 🔧 **Zero dependências** externas

> **⚠️ Mas fique à vontade**: caso seu time prefira, pode continuar usando ESLint + Prettier normalmente.

## 🧱 Arquitetura de Infraestrutura

Nossa stack de infraestrutura será baseada em **Cloudflare**:

- **Cloudflare Pages**: deploy automático do Shell (spotify-mfe-shell-core)
- **Cloudflare R2**: armazenamento dos MFEs versionados
- **Cloudflare Workers**: API pública leve para o Shell
- **Cloudflare D1**: banco de dados embarcado, se necessário
- **GitHub Actions**: será utilizado futuramente no CI/CD

## 🧱 Criando o Shell com Single-SPA

Vamos dar o primeiro passo criando a estrutura inicial com o CLI do single-spa:

```bash
npx create-single-spa --moduleType root-config --moduleFormat esm
```

Durante a criação, escolhemos:

- **Linguagem**: TypeScript
- **Framework**: Nenhum (o shell será agnóstico)
- **Gerenciador de pacotes**: pnpm

Por enquanto, paramos aqui. Nos próximos conteúdos, conectaremos os MFEs com SystemJS, criaremos o import-map e cuidaremos do roteamento.

## 🚀 Deploy com Cloudflare Pages

Enquanto o CI/CD com GitHub Actions não é implementado, faremos o deploy manual via Cloudflare Pages:

1. **Crie o repositório** `spotify-mfe-shell-core` no GitHub
2. **Vá até Cloudflare Pages** e conecte o repositório
3. **Configure**:
   - Build: `pnpm run build`
   - Output: `dist`
4. **Salve e pronto!** Seu Shell estará no ar 🎉

## 🤝 Quer Contribuir?

Esse projeto será **open-source e colaborativo**. Se você quiser acompanhar de perto ou participar da construção:

- 👉 **Grupo MFE Brasil**: [https://spotify.mfe-pro.com/](https://spotify.mfe-pro.com/)
- 💬 **GitHub**: [https://github.com/mfe-brasil/spotify-mfe-core](https://github.com/mfe-brasil/spotify-mfe-core)
- 💬 **Discord**: [https://discord.gg/VX7gdw5P](https://discord.gg/VX7gdw5P)

## 📌 Próximo Passo: Design System

Agora que estruturamos os MFEs e criamos o shell, é hora de olhar para algo essencial: o **Design System**.

Nos próximos artigos, vamos:

- 📐 **Mostrar como o Design System** une os MFEs visualmente
- 🧩 **Criar o spotify-mfe-design-system** com tokens e componentes reutilizáveis
- 🔄 **Ver como consumir** esse styleguide em React, Vue, Angular e Svelte
- 📦 **Falar sobre versionamento** e uso modular em runtime

O Design System será a base da consistência e da produtividade dos times.

## 💬 Curtiu Essa Abordagem?

Se você está construindo algo parecido ou quer tirar dúvidas, comenta aqui ou participa do grupo MFE Brasil. A ideia é construirmos juntos essa plataforma de forma aberta e prática.

*Este é o segundo artigo da 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).*