Programação B

Organizando o Projeto: Monorepo

Em Introdução ao Desenvolvimento de Aplicações, vimos que uma aplicação é composta de vários componentes: backend, frontend web, frontend mobile, banco de dados. Cada um desses componentes tem seu próprio código, suas próprias dependências e seus próprios scripts de execução.

Uma pergunta natural é: cada componente deve ter seu próprio repositório, ou todos devem ficar juntos em um único repositório?

Monorepo vs. Multi-repo

Existem duas abordagens principais:

• Multi-repo: cada componente vive em um repositório separado. O backend fica em github.com/equipe/backend, o frontend web em github.com/equipe/web, o mobile em github.com/equipe/mobile.
• Monorepo: todos os componentes vivem no mesmo repositório, em diretórios separados.

A abordagem multi-repo parece mais organizada à primeira vista, mas na prática ela cria problemas de coordenação. Quando uma mudança no backend exige uma mudança correspondente no frontend (por exemplo, renomear um campo da API), você precisa abrir dois pull requests em repositórios diferentes, e garantir que os dois sejam mesclados juntos. Versões ficam dessincronizadas. Configurações são duplicadas.

A abordagem monorepo simplifica isso: uma única alteração que corta o backend e o frontend fica em um único commit, um único pull request, uma única revisão. A equipe inteira vê o projeto como um todo, não como peças separadas.

A estrutura típica de um monorepo para uma aplicação com backend, web e mobile é:

meu-projeto/
├── backend/
│   ├── src/
│   ├── package.json
│   └── tsconfig.json
├── web/
│   ├── src/
│   ├── package.json
│   └── tsconfig.json
├── mobile/
│   ├── src/
│   ├── package.json
│   └── app.json
├── .gitignore
└── README.md

Cada diretório (backend/, web/, mobile/) é um componente independente, com suas próprias dependências e configuração. Mas todos vivem sob o mesmo repositório Git, compartilhando o mesmo histórico e o mesmo processo de revisão.

É essa a estrutura que o TamoJunto seguirá. Quando chegarmos ao próximo capítulo, vamos montar o repositório com esses três pontos de entrada.

Quando usar multi-repo

Monorepo não é sempre a melhor escolha. À medida que o projeto cresce e equipes diferentes ficam responsáveis por componentes diferentes, um monorepo pode se tornar lento (muitos arquivos, histórico grande) e ruidoso (notificações sobre partes do código que não te interessam). Grandes empresas como Google e Meta usam monorepos com ferramentas especializadas para lidar com essa escala. Projetos menores, como o que construiremos neste curso, se beneficiam da simplicidade do monorepo sem sofrer essas desvantagens.

A regra é simples: se a equipe é pequena e os componentes mudam juntos, comece com monorepo. Se os componentes forem verdadeiramente independentes (equipes diferentes, ciclos de deploy diferentes, nenhuma interface compartilhada), multi-repo faz mais sentido.