I'm from a startup in India called Hypto. We are i...
# server
k
I'm from a startup in India called Hypto. We are investing in building some infrastructure and web-services in the fintech space and was exploring gRPC and Kotlin coroutine based server for our webservices. Managed to put together a basic starter for this - https://github.com/hwslabs/grpc-kotlin-starter At some point, we would need to generate clients across multiple programming languages. I'm thinking we should separate the proto files alone into an independent repo and include that as a dependency in the build process of various other repos (each of which is a different programming language). One of those could be the Kotlin server side impl and others would simply be the language-specific client impl. Any thoughts? Has someone tried something like this?
m
Hi Kartick, in Expedia where I work, we have a single proto repository for all business domains. Then we have a repository for each gRPC target language needed (currently JVM, JS and Go), which includes the proto repository as a git submodule. This way any changes to the proto files can be easily pulled in. Each of these repos serve to build a library with the generated code, specific to its target language. So the “business-domains-jvm” builds a Jar for Java/Kotlin, the “business-domains-js” a Node module, and so on.
🙏 1
k
Do you have a possible sample of this repo structure open sourced by any chance?
m
I’m really sorry, they are private to our GH enterprise installation, they’re not open source.
k
No issues. Do you still use gradle to build the top level repository that includes the proto submodule? Is there a force-use or does Expedia leave it to the discretion of independent teams to use (or pull) the latest proto files?
I know I am asking about a much larger build-system/versioning-strategy question here. But any help here is much appreciated 🙂
m
We use gradle, yes. When you build the top-level repo in CI (which produces the library), the latest changes are always pulled
when you develop/test in local you can do whatever you want with the submodule, update or not, change branch, etc