this was not specifically with protos, it’s possible that it makes sense to centralize those in some way (but it still worries me that you’d have to version a bunch of diverse service definitions together).
Protos have some relatively unique characteristics and pathologies that push me to recommend this pattern, where I wouldn’t necessarily do so for other “shared dependencies” (though I think I probably still favor a monorepo in most situations).
They’re fairly distinct as far as build targets go, since you often end up generating packages in multiple languages, and the relevant versioning strategy is per-build-target, not per-source-file. It is important to avoid the issues with inappropriate shared dependencies across protos that I mentioned in the article because that is one way you run into trouble with versioning, but imo the solution to that is “programmatically enforce proper separation of concerns within the monorepo”.
this was not specifically with protos, it’s possible that it makes sense to centralize those in some way (but it still worries me that you’d have to version a bunch of diverse service definitions together).
Protos have some relatively unique characteristics and pathologies that push me to recommend this pattern, where I wouldn’t necessarily do so for other “shared dependencies” (though I think I probably still favor a monorepo in most situations).
They’re fairly distinct as far as build targets go, since you often end up generating packages in multiple languages, and the relevant versioning strategy is per-build-target, not per-source-file. It is important to avoid the issues with inappropriate shared dependencies across protos that I mentioned in the article because that is one way you run into trouble with versioning, but imo the solution to that is “programmatically enforce proper separation of concerns within the monorepo”.