MonoRepo and MultiRepo which should you consider for your next project?

What is a Repo?

A repo is a centralized digital storage that developers use to make and manage changes to an applications source code. (Source AWS).
A repo foresters collaboration on project very easily among devs.
A repo is not a git!
Repo is built on top of git or a version control system hence a repo can have several "git" repositories.
When working on a small project you won't need to worry much about monorepo or multirepo environment but concern yourself with a version control of your application. However when work on large applications ( like Google, LinkedIn, or Meta) it is crucial for developers to understand the application's repo and coding standards especially syntaxing ( eg. CamelCase for classes and snake_case for functions)

What is MonoRepo?

A monorepo is one central hub for all the application packages. Windows and Linux is built in a monorepo. Google, Meta, AirBnB and Uber use this approach. All code changes are pushed to the central hub.

Pros

• Easy cross project changes are easy: For instance one utility class can be changed and all services that uses that interface will be aware and don't need to any extra works. (eg. Changing mailing server for the project)

• Dependencies Management is easier: All services use the same dependency version and all services (devs) are aware of the dependencies that are available for the project.

• Promotes Consistency in codes: All developers follow the same design, coding patterns and rules as everyone is playing by the rules.

• Code Reuse: if a functionality has already been implemented in a service another service wouldn't need to create the same functionality again. Eg. An email utility class created for authentication system that sends email verification emails; the same function can be used to send order status, promos and news letters emails.

Cons

• Despite the benefits here are some challenges of monorepo It requires carefully planning and tooling like Bazel which was created by Google and Buck by Meta
• Slow CI/CD pipeline because of intensive code reviews and testing.

• The repo can be overwhelming to new developers if repo is not documented properly.

• Customization of services to suit devs is challenge because there are rules and standards they must follow. If a service requires a specific version of a library and that's not available at the repo dependency level this can cause that service to fail. Major changes need to consider the entire repo code base.

Tools like Bazel and Bucks can balance these tradeoffs. By the way they are open source. If you would like to do articles on them let me know in the comments

What is MultiRepo?

Services and Components are treated as separate entities; each service has its own dependencies, libraries and utility classes. It's decentralized unlike a monorepo that is centralized. LinkedIn, Amazon and Netflix uses this appapproach.

Pros

• Independence of services and Teams: Devs can manage and scale their respective repo (service) without concerning themselves with others

• Risk Isolation: if a library or dependency in one repo becomes vulnerable it doesn't affect other repos or services even though the whole project might fail but it only requires "rescuing" only that repo.

• Flexibility: Teams can select tools for their repo and environment for their service requirements

• Clear ownership of repo among teams reduces responsibilities of teams as they are to concern themselves with their respective repo. (Mailing service devs wouldn't worry about Order service)

Cons

• Cross platform changes can be a nightmare. It will require collaboration and specialized tooling to achieve this, such tools include Nexus and Artifactory.

• Different coding standards among teams. This can result in poor code quality and inconsistency but this can be mitigated through establishing an organization wide coding standards.

• Code duplication is paramount. Because there might be no project wide shared utility classes and functions each service team will have to implement these classes and functions in their service even though other services may have implemented them already. Creating shared libraries can help mitigate this issue.

Which to choose for your next project?

There's a gray shade when choosing between the two. Factors such as team size, organization size, nature of project, modularity, security and many more will affect your choice. You have plan ahead and with teams come out what will best the project and the devs.

However if you want consistency, smooth cross project change, code reusability and have large teams then monorepo will be a great suite and will require upfront planning and tooling.

If you want flexibility, risk isolation, clear ownership and responsibility among devs then multirepo will be a great fit. This prioritizes team autonomy.