4 ms·
Just curious, why is using a monorepo a useful trick? I would think it'd be better to have internal libraries that provide common functionality across services
by philote 4y ago
Just curious, why is using a monorepo a useful trick? I would think it'd be better to have internal libraries that provide common functionality across services, and have a repo for each service. Otherwise, you're deploying code changes for one service that could, in theory, mess with another service that you don't maintain.
- gen220 4y agoIn a phrase, it's having a single "bleeding edge" for the entire company, vs 1 bleeding edge per service. Some benefits of this include: You have one commit hash in one repo that tells you what version service/consumer X is expecting / providing. If you want to understand why a service isn't working as expected, it's trivial to grep its implementation and contribute solutions. As a service owner, you can grep for all places where your service's client is initialized, and update them in one PR (vs 12 PRs in 12 repos, that you have to manage independently). Basically, it reduces the coordination cost of breaking changes. --- You can get these benefits in a multi-repo setup only if you have adequate tooling around multi-repo PRs, code search, etc. It's not impossible, but the barrier to highly effective work is higher, imo.
- deleted 4y ago[deleted]