> Getting all of these technologies to work together was a real challenge. I had to dig through countless GitHub issues and dozens of example projects to make all these things work together. I'm offering this repo as a starter pack for other people with a Bazel monorepo targeting Kubernetes.
So, if it was such a hassle just to get them all glued together- how would they fair for a project that adopts it and matures?
It was a hassle mostly because a lot of the libraries are new and the interfaces are still changing a lot. Bazel is a fantastic build tool that I'd recommend for large projects. The Bazel + gRPC story, though, has a ways to go.
But I don't see any reason why you shouldn't use Bazel + gRPC for a larger project. You may have to tweak small things in the future but I suspect that the UX will only improve. Plus, you can always write your own Skylark rules if Bazel isn't cutting it for you in some way.
It's been a while since I looked at this but ~6 months ago I was surprised to find that there are no official bazel rules you can just import to make gRPC "just work." As a result various third-party incarnations exist and they differ slightly in their usage. When you try to compile a basic service it's pretty frustrating.
I really wish gRPC team would come out with rules you can import and best practice examples / tutorials :(
(I work at google but opinions are my own. I don't work on gRPC. I don't have to write much skylark normally because Google infra teams write the common rules you need. I found that writing my own skylark for project outside of work isn't that fun.)
Things have improved but only marginally. Java and Go are the only languages that have "native" gRPC support in Bazel. For others you need to rely on an external repo whose connection to Google is unclear (https://github.com/pubref/rules_protobuf). I find this disappointing, as a gRPC-connected microservice architecture that Just Works and easily interoperates with Docker/Kubernetes/whatever seems like it could be THE "killer app" for Bazel. I built this project to say "look, it's easy!" But alas, it wasn't, and I've communicated that to some core Bazel folk.
I must say, Java was pretty seamless. I followed the instructions and it came together quickly. Go was harder because there's a vendoring issue (surprise!) in that Bazel requires two versions of the gRPC for Go library ("google.golang.org/grpc"), one for Bazel, the other in Go's vendor directory. Gazelle tries to make you use the vendored version, which leads to a conflict, so I had to figure out how to disable that default behavior, which took a few hours of banging my head against the wall followed by reaching out to the Bazel Google Group, which quickly yielded a workaround (thanks, Ofer!).
Beyond that, the real issue is that no other languages have "official" gRPC support, i.e. support from the core Google team rather than from third parties. I do hope that they expand the number of languages soon.
So, if it was such a hassle just to get them all glued together- how would they fair for a project that adopts it and matures?