4 ms·

> It’s a nightmare to handle and use Quite the opposite, IMHO. Juggling dozens of PRs across many repos for a simple change is the definition of a nightmare.

sethammons 3y ago
that tells me you prematurely split something. I worked at a high scale, high available system with multiple dozens of teams, each with several repos. If we had to sync changes across repos, we joined the repos because they were, well, joined. In the early days, we had shared libraries and keeping those in sync was a pita. Then we realized we should not be doing what we were doing. The flow should be: (1) update a library and release it, preferring backwards compatible changes or a new major version; (2) code that wants/needs the new functionality updates the usage at its leisure. If you are having to keep multiple repos "in sync" with each other, yes, you picked the wrong abstraction. If the downstream repo(s) need to always be on the latest and greatest version of the library, the library code should be vendored with the calling code.
- gtirloni 3y ago
  > (2) code that wants/needs the new functionality updates the usage at its leisure. That's how you end up with infinite support costs in a large org. I think the point is that these changes are done atomically.
  - erik_seaberg 3y ago
    You can't deploy a distributed system atomically, and the closer you get the more risk you're taking with prod. The old and new versions need to coexist for at least a couple of weeks in case of rollbacks.
  - sethammons 3y ago
    that is the theory. The reality is that your team can work on fixing an issue now, but the consuming team might be able to get to it next quarter due to competing priorities. Getting multiple teams to agree to work together at the same time is much, much harder than allowing teams to update on their own schedule. You do eventually have to press the organization and deprecate the older thing. The alternative is you do the work for them - which you may or may not have the expertise for, and the other team may not even have time for the needed code review.
radicality 3y ago
Agreed. For the last three years I’ve been working at a company with literal thousands of repos, and it’s an actual nightmare compared to a well maintained monorepo (eg Facebook/Meta). Sometimes updating some library code means I do 50+ PRs across random repos.
- layer8 3y ago
  You’re comparing two extremes, and your last sentence just indicates that the modules don’t seem to be properly divided along stable abstraction boundaries.

sethammons 3y ago

that tells me you prematurely split something. I worked at a high scale, high available system with multiple dozens of teams, each with several repos. If we had to sync changes across repos, we joined the repos because they were, well, joined. In the early days, we had shared libraries and keeping those in sync was a pita. Then we realized we should not be doing what we were doing. The flow should be: (1) update a library and release it, preferring backwards compatible changes or a new major version; (2) code that wants/needs the new functionality updates the usage at its leisure. If you are having to keep multiple repos "in sync" with each other, yes, you picked the wrong abstraction. If the downstream repo(s) need to always be on the latest and greatest version of the library, the library code should be vendored with the calling code.

gtirloni 3y ago
> (2) code that wants/needs the new functionality updates the usage at its leisure. That's how you end up with infinite support costs in a large org. I think the point is that these changes are done atomically.
- erik_seaberg 3y ago
  You can't deploy a distributed system atomically, and the closer you get the more risk you're taking with prod. The old and new versions need to coexist for at least a couple of weeks in case of rollbacks.
- sethammons 3y ago
  that is the theory. The reality is that your team can work on fixing an issue now, but the consuming team might be able to get to it next quarter due to competing priorities. Getting multiple teams to agree to work together at the same time is much, much harder than allowing teams to update on their own schedule. You do eventually have to press the organization and deprecate the older thing. The alternative is you do the work for them - which you may or may not have the expertise for, and the other team may not even have time for the needed code review.

radicality 3y ago

Agreed. For the last three years I’ve been working at a company with literal thousands of repos, and it’s an actual nightmare compared to a well maintained monorepo (eg Facebook/Meta). Sometimes updating some library code means I do 50+ PRs across random repos.

layer8 3y ago
You’re comparing two extremes, and your last sentence just indicates that the modules don’t seem to be properly divided along stable abstraction boundaries.