8 ms·

IANAMU (I Am Not A Monorepo User), but as far as I understand monorepos and their advantages, I'm not sure what the use-case for this tooling is. Most of the t

by derefr 5y ago

IANAMU (I Am Not A Monorepo User), but as far as I understand monorepos and their advantages, I'm not sure what the use-case for this tooling is. Most of the time, when an org chooses to move to having a monorepo (rather than just being left with one by accident of history), the key advantage they're striving to attain, is the ability to make changes to cross-cutting concerns across many distinct applications/libraries, with single commits/PRs. To change an API, and all of its internal callers, atomically, without having to worry about symbolically binding the two together with dependency version constraint resolution. Which is to say, the key advantage of a monorepo comes from having the whole monorepo checked out locally.

bognition 5y ago
They are very useful when you've got hundreds of engineers working on distinct projects that are loosely connected. Imagine you have a team working on core libraries, a few product platform teams, and finally a team working on a customer facing feature. The feature team commits to master and a build kicks off (build 1), that build fails for an unrelated issue (say the build node dies) and the build kicks off again (build 2). With multiple layers of libraries supporting the feature team, its entirely possible that a dependency could have changed and the end result of build 2 would be different than build 1. When each commit shares a common timeline it is really easy to rebuild build 1 with the exact same dependencies.
- derefr 5y ago
  Git submodules already solve that problem, though. As does publishing all the core libraries etc. as language-ecosystem packages on a private package namespace or internal corporate package repository, and then resolving/locking the language-package dependencies to specific tags/refs with a lockfile that gets committed to the downstream repo. These are the "obvious" solutions to this problem, the first ones the average software architect would reach for. What would lead them to ignore these options and choose a monorepo instead, if not for what I mentioned above — the ability to make atomic changes to cross-cutting concerns?
  - chiefalchemist 5y ago
    I've resisted - for too long? - submodules as I've always heard they can be problematic; that the actual implementation isn't quite what I should be.
  - justaguy88 5y ago
    Git submodules have an annoying attribute: double commit First you commit/push to one repository Then you update the submodule pointer in the parent repository
  - zerkten 5y ago
    >> These are the "obvious" solutions to this problem, the first ones the average software architect would reach for. They would have been, except the experience working with them was somewhat problematic for those who have been down this path, and the message that many devs have received is to avoid them. I kind of agree with going to submodules, but confidence doesn't seem to have been rebuilt.
oftenwrong 5y ago
I think there are some potential applications. For example, you want to have a project in the monorepo, but also share it outside of your organisation, and even have external contributions brought back in. Or, you are working in a project in the monorepo, but you don't want to (or can't) check out the entire repo. You can still checkout just that project and its deps. Or, you are working in a polyrepo-using organisation, and you want to experiment with using a monorepo while continuing to allows devs to work in the polyrepos that it is composed from. No big-bang cutover necessary.
- chrschilling 5y ago
  Yes that it exactly the idea. Translating between both mono and poly repo, partial sharing with others (distributed development) and gradual adoption without a big bang.
majormajor 5y ago
When I've used a monorepo, that was one of the explicit goals. Avoiding "here's my new library version, go see if it breaks your shit" was the goal - you make a change, you run the tests, you see if the whole company's code can still build or not. Having fully-separate projects in directories in the monorepo using published dependencies was considered an antipattern (though it was very hard to keep some teams from doing that). The disadvantages of the resulting monorepo weren't "this directories are so big to keep checked out when I'm just working on one specific project" it was "our old build times and build tools are dying under the strain and even trying to move to a 'monorepo friendly' build tool might be an intractable problem because our dependency graph has become such a mess of spaghetti." A monorepo that was done well from the start so you don't have the slow-spaghetti-build problem from months or years of "oh it's easy to depend directly on this full other module, let's just do that" sounds very appealing. We just didn't pull it off in practice, and this project would ... maybe... help in the early stages by letting people have more restricted checkouts? But only if you already know what you're doing anyway.
- roughly 5y ago
  The basic problem with trying to solve the problems with versioned releases with monorepos is that the code in the repo and the code in production are not the same. If you change your service’s API, just updating all of the other clients of your service in the repo is not sufficient to skirt the problem of different clients expecting different APIs. Re the tooling issue, I’ve frankly never seen it solved. I presume Google’s done it, because they’re a bit messianic about the whole thing, but outside of them, I suspect all monorepo implementations fit into the “Communism” model of working great in theory.
  - throwaways885 5y ago
    > If you change your service’s API, just updating all of the other clients of your service in the repo is not sufficient to skirt the problem of different clients expecting different APIs. Most Google APIs are written in protobuf, which is backwards compatible over the wire. This makes most changes painless, although caveat emptor as things can still get messy as they do in the real world. With something like a Java interface, it doesn't really matter if those APIs change because all the code is built and released together at HEAD.
wildmanxx 5y ago
The ability to do some changes like that is not the same as doing it always. Most commits are quite localized, and those should not be penalized by the ability to have a few cross-cutting ones.
chrschilling 5y ago
IATAOJ (I Am The Author Of Josh) ;) You are absolutely right about the main motivation of using a monorepo: Allowing upsrteam library maintainers to see downstream usage of their code and make the required downstream changes themselves at the same time they change their libraries. Also like you say the easiest way to get those advantages is to just check out the monorepo locally, so if there are no other reasons preventing you from doing just that, go for it. However there are a few reasons why this is not always sufficient: Size: The repo might be so large that cloning it all will makes local tools (git cli, guis,...) slow to use, or in the most extreme case require to much disk space for your machine. To address this there are some git native tools like partial clone and sparse checkout, so size alone is not really the the main issue for us. History "pollution": Having a lot of somewhat loosely related projects in one tree means a history that shows all the changes. Yes git can filter them, but once again that might be a performance concern, but once again not really the biggest motivation to create a new approach/tool. Permissions: In some organisations (like the one I work for) it is not possible to give all developers access to all the code and thus the advantages of monorepo get lost just by trying to comply with data protection standards. The only solution with native git is to split the repo at legal (not necessary technical) boundaries and try to coordinate the changes across those. Loosing most of the benefits described. Josh does not have a full blown permissions system yet, but the concept certainly allows for it and implementation is work in progress. Sharing with others (aka, distributed VCS): This is the biggest motivation for using something like Josh. The partial repos are repos in their own right and all the distributed features of git can be used with them. In a monorepo setup as you describe distributed workflow is sacrificed for monorepo advantages. Only developers in the same monorepo see the same sha1s and can easily exchange changes. In Josh the same library can be part of different monorepos at different organisations and while the monorepos have different history and therefore sha1s, the “projected” or “partial” library subrepos will have compatible history with identical sha1s. In this way Josh can serve as a bridge between organisations using different repo structures.
- thrtythreeforty 5y ago
  This is a really interesting approach. How would you layer CI logic on top of this? Given your example workspace josh file, dependencies = :/modules:[ ::tools/ ::library1/ ] how are the canonical build artifacts for, say, ::library1/ determined, and how are they presented to the workspace? I understand that the partial repo layering is the key innovation that exists a layer below what I'm talking about, but I'm trying to understand how you can ergonomically layer never-build-twice logic on top of it.

by derefr 5y ago

bognition 5y ago

They are very useful when you've got hundreds of engineers working on distinct projects that are loosely connected. Imagine you have a team working on core libraries, a few product platform teams, and finally a team working on a customer facing feature. The feature team commits to master and a build kicks off (build 1), that build fails for an unrelated issue (say the build node dies) and the build kicks off again (build 2). With multiple layers of libraries supporting the feature team, its entirely possible that a dependency could have changed and the end result of build 2 would be different than build 1. When each commit shares a common timeline it is really easy to rebuild build 1 with the exact same dependencies.

derefr 5y ago
Git submodules already solve that problem, though. As does publishing all the core libraries etc. as language-ecosystem packages on a private package namespace or internal corporate package repository, and then resolving/locking the language-package dependencies to specific tags/refs with a lockfile that gets committed to the downstream repo. These are the "obvious" solutions to this problem, the first ones the average software architect would reach for. What would lead them to ignore these options and choose a monorepo instead, if not for what I mentioned above — the ability to make atomic changes to cross-cutting concerns?
- chiefalchemist 5y ago
  I've resisted - for too long? - submodules as I've always heard they can be problematic; that the actual implementation isn't quite what I should be.
- justaguy88 5y ago
  Git submodules have an annoying attribute: double commit First you commit/push to one repository Then you update the submodule pointer in the parent repository
- zerkten 5y ago
  >> These are the "obvious" solutions to this problem, the first ones the average software architect would reach for. They would have been, except the experience working with them was somewhat problematic for those who have been down this path, and the message that many devs have received is to avoid them. I kind of agree with going to submodules, but confidence doesn't seem to have been rebuilt.

oftenwrong 5y ago

I think there are some potential applications. For example, you want to have a project in the monorepo, but also share it outside of your organisation, and even have external contributions brought back in. Or, you are working in a project in the monorepo, but you don't want to (or can't) check out the entire repo. You can still checkout just that project and its deps. Or, you are working in a polyrepo-using organisation, and you want to experiment with using a monorepo while continuing to allows devs to work in the polyrepos that it is composed from. No big-bang cutover necessary.

chrschilling 5y ago
Yes that it exactly the idea. Translating between both mono and poly repo, partial sharing with others (distributed development) and gradual adoption without a big bang.

majormajor 5y ago

When I've used a monorepo, that was one of the explicit goals. Avoiding "here's my new library version, go see if it breaks your shit" was the goal - you make a change, you run the tests, you see if the whole company's code can still build or not. Having fully-separate projects in directories in the monorepo using published dependencies was considered an antipattern (though it was very hard to keep some teams from doing that). The disadvantages of the resulting monorepo weren't "this directories are so big to keep checked out when I'm just working on one specific project" it was "our old build times and build tools are dying under the strain and even trying to move to a 'monorepo friendly' build tool might be an intractable problem because our dependency graph has become such a mess of spaghetti." A monorepo that was done well from the start so you don't have the slow-spaghetti-build problem from months or years of "oh it's easy to depend directly on this full other module, let's just do that" sounds very appealing. We just didn't pull it off in practice, and this project would ... maybe... help in the early stages by letting people have more restricted checkouts? But only if you already know what you're doing anyway.

roughly 5y ago
The basic problem with trying to solve the problems with versioned releases with monorepos is that the code in the repo and the code in production are not the same. If you change your service’s API, just updating all of the other clients of your service in the repo is not sufficient to skirt the problem of different clients expecting different APIs. Re the tooling issue, I’ve frankly never seen it solved. I presume Google’s done it, because they’re a bit messianic about the whole thing, but outside of them, I suspect all monorepo implementations fit into the “Communism” model of working great in theory.
- throwaways885 5y ago
  > If you change your service’s API, just updating all of the other clients of your service in the repo is not sufficient to skirt the problem of different clients expecting different APIs. Most Google APIs are written in protobuf, which is backwards compatible over the wire. This makes most changes painless, although caveat emptor as things can still get messy as they do in the real world. With something like a Java interface, it doesn't really matter if those APIs change because all the code is built and released together at HEAD.

wildmanxx 5y ago

The ability to do some changes like that is not the same as doing it always. Most commits are quite localized, and those should not be penalized by the ability to have a few cross-cutting ones.

chrschilling 5y ago

IATAOJ (I Am The Author Of Josh) ;) You are absolutely right about the main motivation of using a monorepo: Allowing upsrteam library maintainers to see downstream usage of their code and make the required downstream changes themselves at the same time they change their libraries. Also like you say the easiest way to get those advantages is to just check out the monorepo locally, so if there are no other reasons preventing you from doing just that, go for it. However there are a few reasons why this is not always sufficient: Size: The repo might be so large that cloning it all will makes local tools (git cli, guis,...) slow to use, or in the most extreme case require to much disk space for your machine. To address this there are some git native tools like partial clone and sparse checkout, so size alone is not really the the main issue for us. History "pollution": Having a lot of somewhat loosely related projects in one tree means a history that shows all the changes. Yes git can filter them, but once again that might be a performance concern, but once again not really the biggest motivation to create a new approach/tool. Permissions: In some organisations (like the one I work for) it is not possible to give all developers access to all the code and thus the advantages of monorepo get lost just by trying to comply with data protection standards. The only solution with native git is to split the repo at legal (not necessary technical) boundaries and try to coordinate the changes across those. Loosing most of the benefits described. Josh does not have a full blown permissions system yet, but the concept certainly allows for it and implementation is work in progress. Sharing with others (aka, distributed VCS): This is the biggest motivation for using something like Josh. The partial repos are repos in their own right and all the distributed features of git can be used with them. In a monorepo setup as you describe distributed workflow is sacrificed for monorepo advantages. Only developers in the same monorepo see the same sha1s and can easily exchange changes. In Josh the same library can be part of different monorepos at different organisations and while the monorepos have different history and therefore sha1s, the “projected” or “partial” library subrepos will have compatible history with identical sha1s. In this way Josh can serve as a bridge between organisations using different repo structures.

thrtythreeforty 5y ago
This is a really interesting approach. How would you layer CI logic on top of this? Given your example workspace josh file, dependencies = :/modules:[ ::tools/ ::library1/ ] how are the canonical build artifacts for, say, ::library1/ determined, and how are they presented to the workspace? I understand that the partial repo layering is the key innovation that exists a layer below what I'm talking about, but I'm trying to understand how you can ergonomically layer never-build-twice logic on top of it.