Arquitetura frontend moderna

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

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.

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

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

Times diferentes, projetos separados, mas que compartilham design system, helpers ou hooks.
Libs que podem viver independentes das aplicações.

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.

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

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

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

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

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

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

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

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