[radicality]

* Why is ownership management a mess in a monorepo? Can just decide “this team owns this folder hierarchy” etc. * ‘Contain blast radius of changes’ - is that actually difficult? Isn’t there tooling that figures out what changed and what dependencies need rebuilding? (eg Facebook buck)

For context, I was for a very long time at FB so am definitely used to the monorepo way, and recently switched to place which uses github + many repos, and it feels so much worse.

Honest question - how do you actually effectively share code between many repos? Example: How do I know that me changing my backend app’s API doesn’t break any other project in the company potentially calling it? It should be a compile/buildtime error for the other project, but how does that work if everything is in its own little repository?

[dragonwriter]

> Honest question - how do you actually effectively share code between many repos?

One way is: Each repo is a responsibility boundary and single source of truth, you use code from other repos the same as any other external dependency.

> How do I know that me changing my backend app’s API doesn’t break any other project in the company potentially calling it?

Changing an API breaks projects using it; you either do versioned APIs and/or coordinate changes with downstream consumers, the same as you would with an API with external customers.

(Another way is “downstream projects checkout their dependencies and build against them as a routine part of their process.“)

[sagarm]

> Changing an API breaks projects using it; you either do versioned APIs and/or coordinate changes with downstream consumers, the same as you would with an API with external customers.

This is a ton of work relative to building/running the tests for all your reverse dependencies and fixing the call sites for them (up to a certain level of scale, of course).

> (Another way is “downstream projects checkout their dependencies and build against them as a routine part of their process.“)

This happens automatically in a monorepo. Any breakages are revealed as soon as upstream makes the change.

[dragonwriter]

> This is a ton of work relative to building/running the tests for all your reverse dependencies and fixing the call sites for them

If someone outside of the team responsible for the functionality at issue can fix all the fall sites for a breaking API change without adversely effecting the domain function of the component making the calls, it's a pretty good sign that there wasn't actually a need for a breaking API change in the first place, and a process change that makes unnecessary API churn more expensive is probably beneficial.

[joshuamorton]

Amusingly I agree with your conclusion that we should discourage breaking API changes, but conclude that monorepos are therefore superior.

Making the team causing the change have to take on the work of migrating clients means that they will make the change as small as possible, and undertake work to to minimize the scope of the change (and make it as backwards compatible as possible).

The alternative is a team publishing a v2.0 API with many incompatibilities and throwing it over the wall, without care that anyone else uses it, and teams eventually needing to migrate to a wholly new API for the one new feature they care about. Or in other words, someone is going to build a compatibility layer, it's more efficient for the owning team to do that, and monorepos encourage that kind of approach.

[giaour]

There are some cases where you have to make a breaking change, and in those cases, it is helpful to be able to assess the fallout without a ton of manual effort. E.g., sometimes a security hole can only be remedied by restricting certain inputs (like with Heartbleed), and that's technically a breaking change.

Monorepos let you make that assessment within a certain scope, as does Amazon's internal build system. It's not a feature you want exercised regularly, but it sure is helpful when you need it.

[giaour]

> Honest question - how do you actually effectively share code between many repos?

Locally, you can use an Amazon-internal tool to check out multiple repos and make changes to all of them. The tooling calls this a "workspace," but it feels very much like working in a monorepo since building and testing can happen at the workspace level.

> How do I know that me changing my backend app’s API doesn’t break any other project in the company potentially calling it?

In terms of change management, Amazon dependency graphs are managed as "version sets." Changes have to be built into a given version set, and that build will also rebuild any package in the version set that consumes the repository whose changes are being built in. (Usually, repositories are configured to build into one of the owning team's version sets on each commit to the primary branch.)