Arquitetura frontend moderna - três principais formas de compartilhar componentes entre aplicações frontend

---

1 – Pacotes NPM (públicos ou privados)

Como funciona

• Você empacota seus componentes (React, Vue, Angular ou até vanilla) em uma biblioteca.

• Essa lib é publicada em um registro de pacotes (npmjs, GitHub Packages, Verdaccio, Nexus etc.).

• Qualquer aplicação que precise desses componentes instala a dependência (npm install minha-lib) e os usa normalmente.

Vantagens

✅ Padronização: ótimo para compartilhar entre múltiplos projetos.
✅ Controle de versão: cada app escolhe qual versão usar.
✅ Independência: não exige repositórios ou builds integrados.
✅ Testado/isolado: a lib pode ter pipeline próprio de testes e versionamento sem interferir nas apps.

Desvantagens

❌ Ciclo de publicação: precisa buildar e publicar cada vez que altera a lib.
❌ Atraso nas atualizações: os projetos consumidores precisam atualizar a versão manualmente.
❌ Mais fricção em times grandes: se os times não sincronizarem as versões, pode virar uma bagunça de dependências.

Quando usar

• Times diferentes, projetos separados, mas que compartilham design system, helpers ou hooks.

• Libs que podem viver independentes das aplicações.

---

2 – Monorepo (Lerna, Nx, Turborepo, Yarn/npm/pnpm workspaces …)

Como funciona

• Todas as aplicações e bibliotecas ficam em um único repositório.

• Cada pacote (app ou lib) fica isolado, mas pode ser importado diretamente entre si.

• Ferramentas como Nx ou Turborepo ajudam no build incremental, caching e orquestração de pipelines.

Vantagens

✅ Feedback rápido: muda na lib → reflete instantaneamente nos apps.
✅ Facilidade de manutenção: todos os pacotes estão no mesmo lugar.
✅ Integração contínua: pipelines centralizados, mais controle.
✅ Ideal para design system: pois fica fácil manter sincronia entre apps e libs.

Desvantagens

❌ Escalabilidade de repositório: repositório pode ficar enorme, lento de clonar.
❌ Dependência organizacional: todos precisam seguir o mesmo fluxo/git.
❌ Coupling: nem sempre faz sentido forçar todas as apps a viverem no mesmo repo.

Quando usar

• Uma organização grande com vários frontends que compartilham design system e regras comuns.

• Times que conseguem alinhar pipeline, CI/CD e versionamento no mesmo monorepo.

• Times de Full Stack developers

---

3 – Module Federation (Webpack 5, Vite plugin, rspack …)

Como funciona

• É um recurso do Webpack 5 (e hoje já tem plugins para Vite, Rspack, Turbopack) que permite que um app importe código de outro app em tempo de execução (runtime).

• Cada aplicação expõe módulos remotos (componentes, páginas, hooks, libs, etc.).

• Outra aplicação pode consumir isso sem precisar rebuildar ou publicar pacotes.

Vantagens

✅ Zero publish: não precisa repack, nem npm publish. Alterou, deployou, já está disponível.
✅ Maior independência de times: cada app é dono de seu deploy, mas ainda compartilha código.
✅ Micro frontends real: permite dividir uma aplicação em múltiplos times e ainda compor tudo no browser.
✅ Versões diferentes em runtime: suporta até “sharing” de libs para evitar duplicação (ex: React).

Desvantagens

❌ Complexidade: configuração de Module Federation exige atenção (ex: versionamento de React).
❌ Acoplamento implícito: se um app remoto mudar a interface sem avisar, o consumidor quebra em tempo de execução.
❌ Performance: mais requests HTTP e runtime overhead. Precisa otimizar.

Quando usar

• Arquiteturas micro frontend distribuídas.

• Times independentes em deploy e release, mas que ainda precisam compartilhar código em runtime.

• Casos onde o tempo de atualização é crítico (ex: e-commerce que precisa atualizar um carrinho ou checkout sem republicar toda a app).

---

📊 Comparação rápida

Método	Atualização	Deploy	Complexidade	Uso ideal
Pacotes NPM	Manual (via versão)	Independente	Baixa	Libs independentes, design system
Monorepo	Instantânea (build integrado)	Centralizado	Média	Equipe única, apps integrados
Module Federation	Runtime (instantâneo pós-deploy)	Independente	Alta	Micro frontends distribuídos

---

👉 Resumindo:

• NPM = bom para libs reutilizáveis e independentes.

• Monorepo = bom para time único ou organização que consegue alinhar ciclo de vida.

• Module Federation = bom para micro frontends e times independentes que precisam compartilhar em runtime.