COcodesuki·May 29, 2018
We are using a similar setup. K8s, Bazel, Go, Java (Android), Swift (iOS), Typescript. Everything with gRPC.
I really like Bazel because it makes working with Protobuf so much cleaner (at least in theory) and allows us to have one build system for all those languages (at least in theory).
The easiest to set up was Go. Go support is already very good, including gRPC and Protobuf.
The only drawback was that it breaks editor integration of some tools / linters because of the different directory layout for generated files.
Vanilla Java also has good support but when you go to Android land things change. At first we had to use a custom fork of grpc-java to build for Android, but with this change https://github.com/grpc/grpc-java/pull/4289 we were able to go back to the main repo.
gRPC-web was a prohibitively large dependency for our front en
Read the rest
d. After all we switched to a JSON API (using Envoy). I read that Google uses gRPC for products like gMail and since Google is so obsessed with web performance I wonder how they manage the dependency size (a few 100kb for us). There is a lot of information scattered around like a json-proto protocol (not publicly available?), which apparently should not be needed with proto3 and newer browser because performance is supposed to be similar. grpc-web uses the official protobuf/javascript package, using protobuf.js the dependency size as well as the compiled protobuf might be smaller.
While building Swift and Objc for iOS was super easy with Bazel we couldn't manage to build our protobuf/grpc. There were no working rules at the time and we had no time to fix it completely which is why we are not building that part with Bazel, yet.
https://github.com/pubref/rules_protobuf/issues/188
I'd appreciate any insights you have on Objc support and grpc-web. It'd be great to be able to use grpc across the whole stack.