Stop using polyrepo (until you read this)

"Monorepo vs polyrepo" is one of important questions that arise when you start working on a new web project. In this article you will learn about basic rules of when to apply either monorepo or polyrepo approach to your web application and the benefits each of the approaches provides.

There are a lot of great frameworks and platforms for developing web applications, front-end and back-end. However, most (all?) of them provide tools for initialization and further work with an application as a standalone repository.

Initially, there's nothing wrong with that: it is the simplest way to get started. But as a consequence, during your web developer career you basically get educated to the polyrepo-first approach.

Later on, as a constantly learning developer, you start to explore what the monorepo is and its potential benefits. So when you start developing your next web application, you ask a fair question: "What are the reasons to use monorepo for this project?"

But the truth is that the power of monorepo approach can very much make us change the thinking direction itself! So upon starting a new web project we now ask: "What are the reasons NOT to use monorepo?"

Monorepo-first approach

Imagine you are starting the work on a new client-server web application (i.e. its architecture contains two nodes: a front-end client and a back-end server). If you choose the monorepo approach for this project, this will provide you a line of benefits.

1. Integrity of development process

Developing a feature usually involves changes in both client and server. With monorepo, all the feature code is wintin a single pull request, which makes development, testing and code review processes more stable.

2. Better deployment automation

Since a new feature code is under a single pull request, it allows you to automate the CI/CD flow for all (affected) nodes upon a single merge. Thus, you are able to re-deploy both client and server as a single operation, and this in turn allows to automate execution of end-to-end tests in correct moments.

3. Easier for pipelines

With some additional tools for managing monorepos you can trigger testing and re-deployment only for the nodes that contain changes and their dependents, aka affected nodes. For example, if you have changes only on the client, you don't have to re-deploy the server. This will reduce overall pipeline usage, which will eventually benefit your wallet and clock.

4. Easier code sharing

If all the nodes of your monorepo are written in the same language (e.g. TypeScript), it is very easy to share code between nodes. For example, you can import data types from server to client, so the client knows which data to expect upon network requests.

All this comes with relatively low cost: one more tool int your toolchain for monorepo management and some additional configuration of your frameworks to adapt them for monorepo.

As you can see, the benefits fo using monorepo outweigh its maintenance costs. And this is a sufficient reason to consider monorepo as a default approach.

When not to use monorepo

Of course, "default approach" doesn't mean "the only approach". Everything is a trade-off, and "monorepo vs polyrepo" is not an exception.

The highlighted benefits of monorepo are the most notable when your development team consists of full stack developers, i.e. when each feature (module) is being developed by a single responsible person.

On the other hand, if you have separate front-end and back-end developers for the client and the server respectively, then the benefits of monorepo diminish.

Another valid reason to consider polyrepo is when you have some kind of secret algorithm or flow on, for example, the server, so you want to restrict access to it only to trusted people. With polyrepo you can achieve that, still being able to involve freelancers for frontend-only tasks.

Conclusion

In this article we have discussed why you should take monorepo as default approach for web development. We have also named valid reasons when you should consider polyrepo for your project.

Of course, as an example we took an application consisting only of two nodes: client and server. But the ideas from this article can certainly be scaled up for more complex architectures.

What is your experience with monorepos and polyrepos? Don't agree with something? Share it in comments!

If you like the ideas from this article and find them useful, don't forget to leave your reaction and follow me on this platform!

Don't stop coding,
don't stop growing,
stand with Ukraine! 🇺🇦