Home > Posts Monorepo vs multi-repo

Max Heinritz

Monorepo vs multi-repo

Most Google engineers operate in a monorepo called google3. It was a joy to work there in the early 2010s, and I’ve heard that the tooling keeps getting better. Google invests heavily in the developer experience for code search, file ownership, version control, testing, commit queue, code review, linting, etc. The code must flow.

So naturally, I have been inclined to follow the monorepo approach at later jobs and recapture that magic. But over time I’ve come to appreciate that most tooling outside of Google is built for multi-repo projects, and it’s best to embrace rather than fight the tooling. Here are some examples:

For future projects, I’m inclined towards:

The separate code bases are also a nice reminder about breaking changes – backend changes to add new API features should be merged and deployed before the frontend changes that use the new features are merged.

Repository naming

I’m inclined toward a repository naming pattern that omits the name of the company itself. Just call the repos backend and frontend. It’s easy to change the company name without needing to rename the repos or change the configuration.