Todos os artigos

Monolito, Multirepo ou Monorepo?

Muitos projetos adotam o modelo de monorepo para estruturar seu repositório. Grandes nomes como Angular, Babel e React, por exemplo, utilizam essa estratégia. Por outro lado, a Uber passou de Monorepo para Multirepo e o VSCode continua sendo um monolito. Qual será a melhor para o meu projeto?

Antes de começar a discutir o quão bom ou ruim é uma estrutura de repositório, acho importante falar um pouco de cada uma delas.

Monolito

Monolito.png
Diagrama de um monolito
Diagrama de um monolito

Esse modelo consiste em ter tudo em um único lugar. Tudo junto e misturado. Geralmente é a mais comum entre os projetos antigos (famoso legado) pois era a forma mais fácil de se começar e continuar um projeto, já que não haviam ferramentas suficientes para se fazer o manuseio de multiplos módulos em um mesmo repositório. Resumidamente: 1 repositório e 1 projeto.



Multirepo ou Polirepo

Multirepo.png
Diagrama de um multirepo ou Polirepo
Diagrama de um multirepo ou Polirepo

Em um cenário onde um projeto possa ser subdivido em múltiplos módulos (ou em vários projetos), podemos atribuir para cada um deles, seu próprio repositório, ou seja, N repositórios para N projetos.



Monorepo

Monorepo.png
Diagrama de um monorepo
Diagrama de um monorepo

Por fim, quando temos vários projetos que compartilham do mesmo repositório, damos o nome a essa estrutura de Monorepo que, em minha opinião, é uma extensão do Monolito, lidando com 1 repositório para N projetos.


Qual dessas estruturas eu devo colocar em meu projeto? Bom, depende…

Minha lista de receitas

Minha lista de Receitas.png
Estrutura simples do projeto inicial
Estrutura simples do projeto inicial

Um projeto é tudo aquilo que tem começo, meio e fim e aqui ele vai ser considerado como algo que possa ser versionado também, para fins ilustrativos. Para exemplificar mais um pouco, vamos criar um projeto fictício para poder acompanhar a gente durante o raciocínio. Consideraremos também que esse é um projeto pessoal que vai sendo desenvolvido conforme as que necessidades vão aparecendo. Nosso projeto se chamará Minha lista de Receitas.


O mais importante aqui é começar. Apenas com a ideia na cabeça, o mais comum de se fazer é criar o repositório vazio seguido por um visual simples.

Dessa forma teremos um projeto para um repositório, caracterizando-o como Monolito. No meu ponto de vista, essa é a estrutura mais simples que esse repositório pode ter e a mais fácil também.

O desenvolvimento vai se saindo muito bem e você fica muito orgulhoso de como ele está ficando bonito. Chega um ponto em que você percebe que seria bom se conseguisse usar seus estilos em um outro projeto, como um pacote separado. Ou seja, você precisa quebrar seu projeto principal em 2 projetos: 1 para o Minha lista de Receitas e 1 para os estilos, que vou chamar de Receitas.Styles.

A partir desse momento a estrutura de Monolito já não comporta nossas necessidades mais (N projetos). Precisamos escolher entre Multirepo e Monorepo.

A escolha

Para o Minha lista de Receitas ou para o que você esteja fazendo, a escolha do que implementar pode variar conforme vários fatores. Pela minha própria experiência, vou listar alguns para ajudar a gente escolher qual estrutura seria a melhor.

Dependências

  • Monorepo: Tudo que envolva seu projeto e subprojetos será instalado, compartilhando aquilo que tiver em comum. No nosso exemplo, se você precisar fazer apenas uma alteração nos estilos, você precisará instalar as dependências tanto do Minha lista de Receitas quanto do Receitas.Styles.
  • Multirepo: Cada repositório tem suas dependências e, mesmo que sejam as mesmas, ficarão duplicadas em sua máquina. Se seus projetos forem do NPM, por exemplo, você terá que usar npm link para fazer com que eles se comuniquem enquanto desenvolve. Se você pesquisar um pouco sobre isso ou mesmo tentar usar, vai ver que não é tão mágico quanto dizem e nem sempre funcionam com outras bibliotecas por aí.

Issues e Pull Requests

  • Monorepo: Todas as issues e pull requests estarão em um único lugar (repositório) e você vai ter que pensar em uma forma de agrupá-las ou diferenciá-las se não quiser ficar tudo misturado e jogado.
  • Multirepo: Sempre que quiser responder uma issue ou mergear um pull request, você vai ter que trocar de contexto, instalar tudo de novo, linkar os projetos pra testar e por aí vai.

Eu colocaria CI/CD como um outro fator importante nessa escolha mas tem um ponto a ser considerado antes. Tanto em Multirepos quanto em Monorepos eu nunca tive problemas em manusear os processos de publicação e/ou deploy. O mais importante é saber as etapas de cada projeto para que seu repositório fique bem.

Dado esses pontos, qual estrutura é a melhor para o projeto Minha lista de Receitas?

Eu, particularmente, escolheria Monorepo por já ter trabalhado com algo similar e, inclusive, implementei a transição de um Monolito para um Monorepo, no React95.

Qual você escolheria?