Monorepo vs múltiplos repositórios: o que funciona de verdade para times pequenos? · obrenoalvim

A discussão de monorepo vs polyrepo voltou à tona com ferramentas como Turborepo, Nx e o crescimento de times fullstack. Qual funciona para times de 2 a 10 pessoas?

O argumento para monorepo

Código compartilhado sem NPM privado. Componentes de UI, tipos TypeScript, utilitários, tudo versionado junto, sem o ritual de publicar pacote para usar em outro repo.

Refatorações atômicas. Você pode mudar uma interface e atualizar todos os consumidores em um único PR.

Contexto unificado. Um dev consegue entender o sistema inteiro sem navegar por múltiplos repos.

O argumento para múltiplos repos

Isolamento. Um repo quebrando não bloqueia deploy de outro.

Permissões granulares. Terceiros (agências, freelancers, parceiros) acessam só o que precisam.

Simplicidade para times pequenos. Um repo por serviço é intuitivo para quem está começando.

O que as ferramentas mudaram

Turborepo e Nx resolveram a maioria dos problemas práticos de monorepo (build incremental, cache, pipeline de CI). O argumento "monorepo é lento" ficou desatualizado.

O problema restante é cultural: monorepo exige mais disciplina de boundaries entre pacotes para não virar uma bola de lama unificada.

Para times pequenos

Se você tem frontend + backend + lib compartilhada: monorepo. O overhead de polyrepo sem infra de pacotes é real.

Se você tem serviços completamente independentes com times diferentes: polyrepo. A separação física reforça a separação organizacional.

Você usa monorepo? O que te fez adotar ou evitar?

Pensando em repositórios que separariam backend e frontend:

Eu penso que é interessante manter junto quando são na mesma linguagem Typescript e eles dividem uma camada de modelo, utilitários e bibliotecas.

Se são backend e frontend em linguagens diferentes, eu penso que devem ser repositórios separados.

Pensando em repositórios que separam módulos da aplicação:

Quando cada módulo tem seu time especializado, eu penso que vale a pena separar em repositórios para cada módulo, mesmo que haja depois um repositório multi módulo abraçando todos eles em uma aplicação única. Neste caso, penso que seria interessante pensar em separar em vários serviços.

Mas se é um time só que trabalha em vários módulos, eu penso em separar por módulos internamente dentro da mesma aplicação, mantendo um repositório único.

Eu trabalho com "monolitozão" com vários módulos onde todo mundo mexe no mesmo repositório. E também trabalho com aplicações onde o frontend e backend são separados cada um com seu repositório.

Depois de sofrer com um "monorepozão", o pessoal criou as outras aplicações já separado.