Hello :wave: Was just wondering how do you structu...

# grpc

[Dariusz Kuc]

Hello 👋
Was just wondering how do you structure your protobuf repos? Based on some articles [1][2] 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]

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]

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]

any comments/feedback would be appreciated

[Marc Plano-Lesay]

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]

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]

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]

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]

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

[Dariusz Kuc]

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

[Marc Plano-Lesay]

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

[Dariusz Kuc]

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

[Dariusz Kuc]

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

[Dariusz Kuc]

...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