What is a Monorepo?
Some web development teams do use monorepo and some of them do not. They are using multiple repository strategies. Here we are going to cover what a monorepo is – and benefits that you get when you start using it.
This concept is not new, instead it is as old as it gets. Google has been using monorepos for their entire database, website, apps etc. for over 2 decades. If this concept is over a decade old, how come I get to hear about it only now?. Mostly is because of the drastic changes that have appeared within the last 5-6 years.
With monorepo and multiple repositories, the advantages of one represent the disadvantages of the other. And vice versa.
Up until now you’ve only read about monorepo. But what about multiple repositories? I mean there must be something to it, right? So, let’s get right into it.
What are Multiple Repositories?
Unlike monorepo where all your code (mobile, web, front & back end etc.) are all stored into one place, in multiple repositories your code is being stored in small boxes scattered all over the place that are interconnected.
And just like monorepo, this concept started over 2 decades ago. Currently being used by multiple companies around the world. Simple because they prefer to limit the accessibility of other developers so they are specialized in one department. For developers that have experience with the financial department and what goes in it, they will be working ONLY on that. Without having access to anything else.
Advantages of Using Monorepo
- Code Sharing.
Most of the time, when you are working with teams, they are duplicating the code for various microservices. If common models, libraries and helper code are stored all in one place, it automatically becomes easier for the team. They are able to share among themselves many microservices. Otherwise, for multiple repositories, all of the libraries have to be connected to a central point from where you can have access.
- Atomic Commits
As all the applications and libraries are in the same repo, this helps in having atomic commits when it comes to cross-application feature implementation. Also, having a single commit across apps makes it easier to be referred in the future.
- Discoverability.
In a monorepo you get a single view of the whole code. With that you can see the repository’s state, screen all the branches and keep track of modifications much more easily.
Like with any other strategy, there are advantages and disadvantages. None of them is perfect. As mentioned above, the disadvantages of one are the advantages of the other. Having said that, let’s take a look at some of the advantages multiple repositories have.
Advantages of using Multiple Repositories
- Able To Restrict Access.
One of the best advantages of the multiplier repository is that you can grant specific access to individual teams. As each team develops a single repository, they do not need to interact with other teams or other repositories. By having restricted access the focus of the entire development team will automatically increase.
- Easier Development Cycles.
Since in a monorepo teams are working with a single, huge code database, in multiple repositories each team is assigned a specific repository. Each team, individually, works on their own repository which results in a way faster development cycle. Also, when you need to introduce changes in a library, you would need help from the other side. And at the end, all that needs to be done is the integration.
- Performance Is Sped Up.
Large scale projects with monorepo and Git do not work so well together as you may expect. The performance of the Git remote actions such as pushing, branching, merging A.S.O takes a tremendous hit because of the large nature of the repositories. Inside multiple repositories it becomes easier since you need to push the code into a specific repository instead of the whole code.
Now that we’ve gone over the advantages of multiple repositories, you can have a clearer picture of their usage. Now I am not claiming that you need one 100%, but I am saying that for specific case scenarios, it’s one of the best tools.
And just like Google and Facebook, which are using their own system, it’s still a monorepo. Very useful when you build large scale applications and you need everything to be in one place.
Final Thoughts
Ultimately, it would be disingenuous to see monorepo and multiple repositories as “good” or “bad” for software development teams. Instead, it’s best to view them as code versioning approaches that have advantages and disadvantages for your specific needs. Some pros may elevate an engineering organization while the others may bring problems along the way.
Whether you choose the monorepo or multiple repositories approach for your project and/or organization, you’ll have to deal with trade-offs in each approach.
No matter which organizational architecture you choose, always take into consideration your team. And the engineering culture inside it. Building software is a social activity and different teams have different ways of approaching it and communicating. Always be smart and carefully evaluate your architecture choice based on your specific situation.
