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

I agree. As much as I really wanted to use gRPC on Go for a current project, this bug ultimately scared me away: https://github.com/grpc/grpc-go/issues/1043

Big kudos to everyone working on it (most of which are Google engineers, some very senior) but I can't help wonder what other issues might be lurking if that one went unnoticed for so long.

The thing that went unnoticed with that issue is that grpc-go didn't have an option to manually increase the window size. Both the Java and C implementations had the option much earlier; I see a commit adding it in Java in March 2015.

At least by August 2015 I was working on automatic window size tuning, which I've not seen in another HTTP/2 implementation to date. July 2016 it was implemented in Java, but remains disabled due to interoperability concerns that we need to spend time addressing. C now implements something similar and it may be enabled in 1.3.

For flow control to work promptly the window size should be only as large as necessary, so there is cause for keeping it small. Since the lower value is appropriate for many networks, it isn't completely outrageous.

I think the biggest failure on gRPC's part here is not having a notice in a widely-read part of documentation informing users to be aware of the limitation. That's easier said than done, but that doesn't negate its importance.

It is worth pointing out that the Python implementation is particularly bad. Perhaps gRPC is really pleasant to use with Java and Go, but the Python implementation is neither usable nor stable enough for it to be worth considering its use for one's own services.

We haven't tried using gRPC in Python, as we have completely migrated from Python away towards Go.

Our experience of using gRPC in Java, C++ and Golang is pretty good. While it had some initial teething issues (when it was first released), the libraries have generally been a non-issue since the gRPC General Availability (GA-1.0 version).

If you're considering using it in Go, check out the https://github.com/grpc-ecosystem/go-grpc-middleware helper libraries that we've contributed back to gRPC Ecosystem.

Ruby too was pretty bad - more so Protocol Buffers than gRPC itself though. In my previous place, I had to fork the Ruby library and write a non-trivial amount of C code so that instances of Protocol Buffers messages could be treated as regular Ruby objects by their callers. Once I opened a PR against upstream it was quickly accepted but took some 6 months to be published to Ruby Gems. I'm not saying to stay away, but please be prepared for surprises.

My instinct would be that it'll be just inherently nicer to use in a statically-typed language.

Python can be statically typed.

Maybe I'm wrong here, but the number of open pull requests isn't a bad thing. If you start poking at them, you will see that people submit pull requests to have the full gRPC test suite run against their changes (which probably includes cross-platform tests). So maybe putting a pull request up is the only way to get Jenkins kicked off, which then means it is part of the standard flow when doing work on the project to test changes.

I own about 15% of those PR's at any given time... and you're right: our Jenkins instance looks at open GitHub PR's, so to run all the tests somewhere, and to verify performance, we open a PR. Many of mine are lower priority things (or exploratory enhancements) and so they'll stay open for even a quarter at a time before it really makes sense to land them.

The author addresses this in the OP:

"We later learned that Google’s gRPC Team was working on a gRPC-Web spec internally. Their approach was eerily similar to ours, and we decided to contribute our experiences to the upstream gRPC-Web spec (currently in early access mode, still subject to change)."

I suspect anyone attempting to adopt this implementation is going to hit similar issues until a release is finalized.

I've been using c++ for the server and python for the client, and it's worked well what issues did you hit?

Number of GitHub issues is not a good metric for quality.