12 ms·

The perceived ease of that operation in a monorepo is what makes it dangerous. Unless these changes all map to a single monolith service, then even though you h

The perceived ease of that operation in a monorepo is what makes it dangerous. Unless these changes all map to a single monolith service, then even though you have updated all call sites, these callers will not be deployed all at the same time, meaning as the change rolls out you may see random breakage. By using polyrepo, the deployment boundary can align with the code boundary, making the rollout problem obvious.

hamandcheese 4y ago
People point this out often, but in practice I have never seen this cause issues. Remove callers first, then remove endpoint... its pretty obvious the order in which things need to be done. What I have seen as a real problem, time and time again, is having trouble locating all usages of an API in a multi-repo scenario. Anyone who fucks this up in a monoreppo will probably fuck it up worse with multiple repos.
- wewtyflakes 4y ago
  I think the tricky issue is updating the structure or semantics of an existent call across services. A monorepo makes it easy to make these kinds of changes in code, while making it non-obvious that it is dangerous to deploy; it is a giant foot-gun. Examples along this line include updating the name of an RPC, or endpoint, or changing the request/response structure, and so on. Of course you could argue that "you just shouldn't", of which I agree, but the point is that then making those kinds changes should actually be really hard, instead of really easy.
  - hamandcheese 4y ago
    Ah yes, this is definitely a challenge. At my day job we use protobuf and follow the (imo well documented and well evangelized) best practice of forbidding breaking changes to protos, so I almost forgot about this class of problem. At least for changes to structure. Changes to semantics can still happen but I don’t know that I’ve ever seen anyone cause a major issue while keeping structures compatible. We have escape hatches, which I mainly use when deleting code.

hamandcheese 4y ago

People point this out often, but in practice I have never seen this cause issues. Remove callers first, then remove endpoint... its pretty obvious the order in which things need to be done. What I have seen as a real problem, time and time again, is having trouble locating all usages of an API in a multi-repo scenario. Anyone who fucks this up in a monoreppo will probably fuck it up worse with multiple repos.

wewtyflakes 4y ago
I think the tricky issue is updating the structure or semantics of an existent call across services. A monorepo makes it easy to make these kinds of changes in code, while making it non-obvious that it is dangerous to deploy; it is a giant foot-gun. Examples along this line include updating the name of an RPC, or endpoint, or changing the request/response structure, and so on. Of course you could argue that "you just shouldn't", of which I agree, but the point is that then making those kinds changes should actually be really hard, instead of really easy.
- hamandcheese 4y ago
  Ah yes, this is definitely a challenge. At my day job we use protobuf and follow the (imo well documented and well evangelized) best practice of forbidding breaking changes to protos, so I almost forgot about this class of problem. At least for changes to structure. Changes to semantics can still happen but I don’t know that I’ve ever seen anyone cause a major issue while keeping structures compatible. We have escape hatches, which I mainly use when deleting code.