Hello wave Was just wondering how do you structure your prot

Question

Hello wave 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

Dariusz Kuc · Answer

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

Dariusz Kuc · Answer

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

Dariusz Kuc · Answer

any comments feedback would be appreciated

Marc Plano-Lesay · Answer

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

Marc Plano-Lesay · Answer

Having a single repo also makes refactorings much easier when protos are involved you can e g rename across the whole codebase for example

Dariusz Kuc · Answer

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

Dariusz Kuc · Answer

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

Marc Plano-Lesay · Answer

I don t know what your build system looks like but generating multiple individual artifacts might be a solution

Dariusz Kuc · Answer

its somewhat problematic due to the a number of interdependencies between different services sharing common objects gt guess would need to untangle the models to some common spaces

Marc Plano-Lesay · Answer

Yeah that can definitely be non trivial for 50+ services I guess

Dariusz Kuc · Answer

since that big jar is consumed by services the 10MB size is not that big of a deal I guess

Dariusz Kuc · Answer

was just thinking about how to get similar workflows going for gRPC REST and GraphQL

Dariusz Kuc · Answer

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 gt seems like much bigger pita than having a monorepo that generates large JAR and potentially can be out of sync with deployed services