Was just wondering how do you structure your protobuf repos? Based on some articles  and stack overflow questions looks like people are leaning towards a monorepo approach but that also means that there is a potential disconnect between the schema and actual server implementation (which can run using older definitions). Guess that it is probably less troublesome than the alternatives....
side note: currently we are also using monorepo approach but was wondering whether it would be possible to avoid the potential diff between schema and running server
splitting up the proto monorepo into a common model one and individual services is doable but would generally imply usage of something like git submodules which are somewhat PITA
any comments/feedback would be appreciated
06/10/2021, 10:40 PM
Personally I'd very much prefer have to dig in the repo history to checkout a tag/commit matching a deployed server if needed than having multiple repos to keep in sync, merge potential conflicts between...
Having a single repo also makes refactorings much easier when protos are involved, you can e.g. rename across the whole codebase for example
06/11/2021, 3:04 AM
well the reason I was looking into splitting stuff up is that our monorepo currently has something like 50+ services already and will be growing (generated JAR with Java/Kotlin stubs is over 10MB (!))
given the number of people working on it there is quite a lot of churn there
when doing the GraphQL or REST definitions we could have those defined locally with the service and publish the corresponding schema to build a federated gateway
06/11/2021, 3:05 AM
I don't know what your build system looks like, but generating multiple individual artifacts might be a solution?
06/11/2021, 3:06 AM
its somewhat problematic due to the a number of interdependencies between different services sharing common objects -> guess would need to untangle the models to some "common" spaces
06/11/2021, 3:07 AM
Yeah that can definitely be non trivial for 50+ services I guess
06/11/2021, 3:07 AM
since that big jar is consumed by services the 10MB size is not that big of a deal I guess
was just thinking about how to get similar workflows going for gRPC, REST and GraphQL
...but splitting up the monorepo into 50+ services that would then have to use git submodule to get common stuff and then getting all those services configured to publish their stubs -> seems like much bigger pita than having a monorepo that generates large JAR and potentially can be out of sync with deployed services