The Monorepo

Many times I find myself in a debate regarding the organization of the source code in a company. And usually, one buzzword is present, or maybe the following sentence:

Lets put everything in a monorepo …

I unerstand the concept, it solves many problems, but at the same time, it create others. Especially, when you have heterogeneous projects.

Imagine that you have an organization that develops, several backend services in Golang and Python, and has also mobile applications for its consumers, thus there is also swift and kotlin on the menu. Ah, I almost forgot, and a fancy SPA (single-page application), so we have nodejs/React and lots of javascript/typescript mixed with HTML/CSS.

The Many-repo approach

Traditionally, each application had its own repository and along with it, it own CI/CD pipeline. This had many benefits, since you could implement specific solutions for each one maintainance and deployment. This can offer you freedom, but it also may increase infrastructure complexity a lot.

One other drawback it is worse in terms of core reusability and sharing. Imagine having an SDK that needs enhancements/improvements in order to implement a specific feature; depending on the language, you may have a real complex mini-release cycle in a staging environment to finalize the implementation, like commit to the SDK repository, then release the library to the staging environment, rebuild the service etc. This process in the end will create a very slow development process.

The Monorepo approach

If you have everything in one repository, then lots of these problems are completely vanished. SDK are inside the monorepo, you can easily juggle, while contributing on many repos, and at the same time, you can easily group platform changes in a single PR (Pull Request), which is really cool actually.

One problem is that you are really messing up the repository history, since many engineers, are merging for various apps inside the monorepo. So, if you want to really see what happens to a single app, then it is an issue.

You may need custom technology, unless you want to checkout everything. Imagine fetching all branches with git, all tags, releases etc. In addition, if you are using Github, then some of its features may be really usuable, like releases, since they tend to create a tag, and a tarball of the latest repository version.

The Github approach (or the virtual monorepo)

My take is that the monorepo is an approach that has meaning only for a specific technology stack eg. all your python code, or Golang code it should be in one repo, since this will promote reusability and transparency for all the developers of the craft.

Everything else can be “simulated” by tooling, custom or not. If you have a tool, that gets information for all repositories in an organization and has views that really work transparently for summarize information of all the repositories, then you have something like a virtual monorepo. So, maybe this is the right approach.

Who can build this for me? :)