ATatombender·Apr 27, 2017
The gRPC project is surprisingly shoddy, given that it's Google's "next-generation" client protocol that's being slowly implemented across all Google products.
The state of the various Protocol Buffers projects isn't great, either. Google's Go implementation produces some awkward Go code, but efforts to increase user-friendliness are generally being knocked down (by Googlers, I think). Pull requests are lying untouched.
There's a fork called Gogo-Protobuf [1] that tries to evolve the Protobuf project and make it friendlier and faster. One way in which it is nicer is that it makes some attempts to make the generated Go code more idiomatic Go. But it's also hobbled by the above problems. The biggest challenges revolve around two areas: The canonical JSON mapping (which is particularly bad at "oneOf" structs), and custom types (Gogo adds thi
Read the rest
ngs like better date/time support).
The Gogo team (understandably) doesn't want to diverge too far from the mainline, but that means open issues are stagnating while the PRs in the upstream Google project are stagnating.
These issues of course then also leak into related projects that extend Protobuf, such as the Go gRPC gateway, which implements a REST proxy on top of gRPC. Since the JSON mapping is so lacking, the JSON data you get out isn't quite idiomatic JSON, which makes the gateway pretty much useless for a lot of applications. (Note: It's been about 6 months since we tried to use it and had to give up, it may have improved since.)
We also ended up forking the official JSON marshal code to work around the various issues with it. Other projects such as CockroachDB also do this.
[1] https://github.com/gogo/protobuf