This content originally appeared on Bits and Pieces - Medium and was authored by Fernando Doglio
Google is doing it, why wouldn’t you?!
Believe it or not, Google is one of the biggest monorepo users in our industry. I’m not making this up, their code base is huge, as you can probably imagine, and reports state that they have 95% of it inside the same repository.
According to this article from ACM.org Google’s main repository had close to a billion files, and that was 6 years ago! They’ve had to distribute it across many data centers, with an architecture of its own to make sure that files were properly replicated and backed up in case of a catastrophic failure in one of these data centers.
After all, code is probably the biggest asset inside Google, maybe second to the actual data they collect.
The interesting bit about this though, is the fact that they keep most of it inside a single repository. They call it “Piper”, it’s their version of Git and they had to write it because Git would not do based on their requirements.
But leaving Piper aside, why would you want to use a monorepo?
Easier visibility
You know that feeling you get when you start implementing that utility function that, maybe, someone in another project, has already implemented something similar?
Well, with monorepos it is a lot easier to answer that question because chances are, if the function was already created, it’s part of your repo. And if you’re dealing with a monorepo that is like Google’s, in the sense that you keep multiple slightly unrelated projects inside it, then that function is probably living inside a utility project that can be used and shared by any of the projects inside your repo.
Of course, this is only true if all teams using the monorepo follow a certain set of rules to make sure that common functionalities are exported, and that projects are isolated from depending on one another as much as possible. Coding best practices are paramount in such a scenario, because the chaos that ignoring them can create is surely going to destroy the repo.
But if you do follow those best practices then you’ll have a very tight and close “community” of tools and teams working and collaborating very close together.
Improved cooperation
In the same line as before, inter-team cooperation is a lot easier inside a monorepo.
Of course, the caveat here is that this is only true if there are very well-defined rules followed by every team.
A monorepo is not the place to let everyone “do their thing”, sort of speak.
Think about it as sharing the house with your in-laws and a few friends and their couples. Everyone pays the exact same amount of rent, so it’s not like there is a single owner to dictate the rules. But you can’t also have everyone live their lives as if it was only their house, because then you’d collide with each other.
You’d try to have lunch when your friend’s kids try to play video games in the living room. And they’d want to take a long shower just the night when you have an important date to attend to.
Now picture that, but with code. Scary isn’t it?
Now imagine that they all had a common set of house rules, and that everyone lived by those rules. Then they would form a small, but well-organized community. And that is what you can get from your monorepo as well, as long as everyone follows the rules.
So take a look around, are you using a monorepo right now? Do you have a very clear, well-defined set of rules to follow? If the answer is “no”, then ask for one or define them yourself and try to get the approval of everyone involved. The sooner you have this “working framework” set up, the sooner you’ll start enjoying the monorepo life.
Better standarization & code reuse
From the above point, once you’ve managed to define and get everyone to agree on, the common “house rules” for the monorepo, then these benefits will organically appear.
When different teams work on different projects under the same code repository, sooner or later they’ll start having similar needs. And what do we hate as developers more than having to release to production on a Friday afternoon? That’s right, re-inventing the wheel.
We hate it, we don’t like doing that. And thus the moment these teams start having needs that they identify as generic within their own domain, they’ll start looking out and asking “hey, do you also need THIS, because we’re already working on a generic version of it”.
And sooner rather than later, you’ll start seeing common libraries and functionalities show up.
Because of that same reason, coding standards will have to be defined. After all, if you’re creating code that will be re-used by others, the best chance everyone has to get the most out of that code, is to write it following the same standards.
This way, you’ll have an easier time integrating external tools, sharing team members and even validating how good these standards are in many different scenarios. Thus being able to get feedback quicker and being able to adapt it into a set of standards that work for everyone within their business domains.
Single source of truth
When you have two versions of the same library, none of them written by your own team, how do you know which one to use? Who’s to tell if they’re both valid and should continue being maintained and developed or if they should both merge into a single one?
Who owns that decision?
That’s why when you start properly taking advantage of a multi-team environment using a monorepo, you’ll see that keeping a single source of truth for your code is the best way to go.
This most likely will involve some recurrent meetings between team leads, to make sure that common code exports (i.e creating new common libraries) get coordinated properly to avoid overlaps.
It might even be a good idea to have something like a “generic libraries committee” where, ideally, representatives from all teams get together and are in charge of coordinating the proper release and maintenance of these emerging new common tools.
Either that, or at least make sure that all teams recognize the “authority” that this GLC will possess in regards to common code, and not ignore it in favor of speed. Because, again, for things to work for the best in a monorepo scenario, rules have to be followed, otherwise chaos will ensue.
Monorepos definitely bring a lot of benefits when it comes to organizing teams working with related projects. They help you improve the way you work, save time with less code and even share devs between projects a lot easier.
That is all true, if you have a very well-defined and accepted set of rules. Otherwise, monorepos can be a true headache for a company.
And from what I’ve seen and from my research, I’d also add that the bigger the company is, believe it or not, the better results they’ll get out of a well-executed monorepo. This is why Google, out of all companies in the world, has one of the biggest monorepos in the world.
Think about it, you might agree with them or not about their products and their data privacy rules. But you can’t argue that they have some pretty big projects and the fact that most of them live inside the same repository is mind-blowing.
What about you? Are you using a monorepo in your company? What are some special rules you’ve had to incorporate to make it work?
Bit: Feel the power of component-driven dev
Say hey to Bit. It’s the #1 tool for component-driven app development.
With Bit, you can create any part of your app as a “component” that’s composable and reusable. You and your team can share a toolbox of components to build more apps faster and consistently together.
- Create and compose “app building blocks”: UI elements, full features, pages, applications, serverless, or micro-services. With any JS stack.
- Easily share, and reuse components as a team.
- Quickly update components across projects.
- Make hard things simple: Monorepos, design systems & micro-frontends.
Learn more
- How We Build Micro Frontends
- How we Build a Component Design System
- How to reuse React components across your projects
- Painless monorepo dependency management with Bit
Why Go Monorepo? was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by Fernando Doglio
Fernando Doglio | Sciencx (2022-06-24T07:28:11+00:00) Why Go Monorepo?. Retrieved from https://www.scien.cx/2022/06/24/why-go-monorepo/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.