Monorepo Part 1: Why and how my chapter switched to a monorepo architecture

The initial discovery

Through this series, I’ll expose how the monorepo philosophy’s perception shift and its inherent tooling enabled my team doing software architecture at scale.

We’ll cover the whole adoption process from discovery to observability.
This blog posts series breaks down into 5 parts:

• Part 1. The discovery (context, pinning down the problems)
• Part 2. The discovery (pros and cons of solutions)
• Part 3. The benchmark (technologies and tooling)
• Part 4. The implementation
• Part 5. The observability phase

Company context premises

2022 is a year of many challenges for Combo, the company where I’m currently Senior Tech Lead and JS Chapter Lead.

One of our north star objectives is to multiply the company’s overall growth. This means (among many other things) for the tech teams to:

• implement new features to reach financial and growth objectives
• to do so, hire and onboard a lot of Software Engineers
• and last but not least, build and enforce a strong Engineering Culture

Tripling the team’s size was definitely the quantitative objective of the year.

Ok fine, but how can we make it as smooth as possible?
How to minimize the newcomers’ onboarding load?
How to enforce an encapsulated set of shared best practices?
How to ease discovery in a multi-squads organization?
How to create a tech culture based on open communication where collaboration is a core value?

Tech frontend repositories premises

At that time the JS-TS repositories’ landscape was composed of 4+ main GitHub repos, hosting the majority of the company’s frontend source code:

• the mobile apps (React-Native)
• the tablet apps (React-Native)
• the backoffice app (React-Express)
• and the web app (React-Express)

This “many repositories policy” brought us several pain points:

• efforts in the configuration must be done in parallel on each codebase
• tooling and libraries can be inconsistent (different version numbers or even different tools)
• best practices decided at the chapter level must be ported in 4+ different repos
• CLI and codebase manipulations are different in each repo (commands, code structure…)
• lots of code is duplicated (time lost writing, maintaining, and testing the same code)
• some changes force the creation of PRs in several repositories (several PRs, reviews, hypothetically different CI pipelines…)

The chapter also had a long-term goal in mind, we wanted to start looking at micro frontend architecture in Q4 (or early 2023).

Listing micro frontend pros and cons is not the initial goal of this article, but simply put, we consider it a necessity for the technical architecture to match the organizational one. If the tech team is split into squads this makes a lot of sense to split the application the same way. (courtesy of Conway’s law)
See you in a few months for a more complete article on that topic!

So, back to where we were.

Performing the architectural evolutions heavy lifting is my squad’s mission: the platform squad. Being the owners of that topic, we started isolating the challenge (aka the ”discovery phase”).

After a few rounds of internal (squad) and external (chapter) discussions and RFCs, we eventually, boiled down the above points to the following problem wording:

How to allow both the sharing of common pieces of software and squad particularities, and simultaneously promote an inclusive tech culture? (Bonus points if the solution could make the architecture lean toward the chapter’s long-term goals)

Once the problem was pinned down, the platform squad was ready to start investigating potential solutions. See you in the next post for a detailed view of what we found.