
gRPC: Internet-scale RPC framework is now 1.0 - vtalwar
https://cloudplatform.googleblog.com/2016/08/gRPC-a-true-Internet-scale-RPC-framework-is-now-1-and-ready-for-production-deployments.html
======
tptacek
Something I've wondered for awhile: why would I want to design with gRPC
rather than well-defined HTTP/JSON endpoints? Is it just a perf thing?

~~~
kajecounterhack
Performance and versioning are two large benefits.

Performance benefit comes from the fact that schema is defined on each side
(generally server / server) so you only send the information bytes. With a
good RPC system you can also access specific fields of your structure without
unpacking (or very fast unpacking, depends on what RPC system you're using).

gRPC uses Google's protocol buffers. [https://developers.google.com/protocol-
buffers](https://developers.google.com/protocol-buffers)

Comparable systems use other IDLs, e.g Facebook uses Apache Thrift.

Versioning is easier because your fields are defined explicitly, so you can
ignore clients sending an old field to no ill effect (again, you can access
individual fields without unpacking). Whereas with json you need to
deserialize first. Also if your schema changes when using json without
protobufs, you may experience either the client or the server making the wrong
assumptions about input data. Whereas there is no ambiguity with protobufs;
future changes to proto messages add fields and old fields can just be marked
deprecated.

RPC is preferable to JSON for server-to-server communication, but client-
server still often uses json just because it's often easier for your client
app to interpret json. Systems like gRPC allow servers to emit json as well:
[https://developers.google.com/protocol-
buffers/docs/proto3#j...](https://developers.google.com/protocol-
buffers/docs/proto3#json)

I've heard of performance-oriented web apps using protobufs on both client and
server.

~~~
heavenlyhash
I'd really love to see something like gRPC implemented over CBOR.

CBOR -- Concise Binary Object Notation -- [http://cbor.io/](http://cbor.io/)
\-- is all the performance of a binary protocol, with semantics basically
identical to JSON.

I appreciate some of the things protobuf does to help you version, but I also
do _not_ appreciate the protobuf compiler as a dependency and a hurdle for
contributors, or for wire debugging. CBOR has libraries in every major (and
most minor) languages and works without a fuss with tiny overhead, both at
runtime and in dependency size. It's pretty pleasant to work with.

~~~
kbaker
There are two reasons why I think simpler binary packing libraries like CBOR,
MsgPack, or BSON can't really match what Protobuf gives you:

\- Assistance with schema evolution and versioning is one of the best parts
about using Protobuf in an API. It is really like the best parts of XML and
XML Schema (validation, documentation, interoperability) without any of the
bloat.

\- Working with code generation can be a pain to get working initially, but is
very friendly when actually using real objects in code. There is no need to
think about any representation on-the-wire... everything 'just works'. There
is no need to ensure you don't accidentally serialize fields in the wrong
order, or worry about encodings, etc.

Also, there is a binary decoder included with protoc that can print a debug
decoding of any protobuf binary message, including integer tags for different
fields. Wouldn't you have pretty much the same problems with dissection and
debugging on-the-wire in CBOR?

It is really quite pleasant to use Protobuf for an API, I can see why Google
is opinionated in including it as the only option with gRPC.

~~~
heavenlyhash
I don't find the utility to outweigh the PITA. I've been on both sides of the
fence, and maintained large projects with heavy protobuf use.

I don't find the schema validation powerful enough. You still have to write
correct code to migrate semantics. Avoiding incorrect reuse of field names
is... nice, but also the most trivial of the problems.

(I do like schemas in theory. It's possible I haven't worked with good
_enough_ tooling around protobufs to really experience joy resulting from
those schemas. The protos themselves certainly aren't guaranteed to be self-
documenting, in some of my experiences.)

I don't find code generation results to be smooth in many languages. At
$company, we switched through no less than _three_ different final-stage code
generators in search of a smooth experience. Not all of this was misplaced
perfectionism: in some cases, it was driven by the sheer absurd method count
verbosity in one code generator basically making it impossible to ship an
application. (You've perhaps heard of the method count limits in early
android? Bam.)

I don't think the debug decoding tools for protobuf are directly comparable to
CBOR's interoperability with JSON. CBOR and JSON are _literally_
interchangable. That means I can flip a bit in my program config and start
using one instead of the other. Config files? Flip the bit. Network traffic
not meant for humans? Flip the bit. Need to debug on the network? Flip the
bit. Want to pipe it into other tools like `jq`? No problem. There's a whole
ecosystem around JSON, and I like that ecosystem. Working with CBOR, I can
have the best of both worlds.

Sometimes opinionated is good and powerful and really makes things streamlined
in a way that contributes to the overall utility of the system. I don't think
this is one of them. Almost every major feature of gRPC I'm interested in --
multiplexing, deadlines and cancellations, standard definitions for bidi
streaming, etc -- has nothing to do with protobufs.

natch, I used "I" heavily in this comment, because I realize these are heavily
subjective statements, and not everyone shares these opinions :)

------
LeonidBugaev
I'll try to jump on the plane, and announce that latest GoReplay version now
supports Thrift and ProtocolBuffers.

So if you are looking to load testing (or integration testing) for gRPC based
apps check [https://goreplay.org](https://goreplay.org)

~~~
Xorlev
Unfortunate that you didn't mention it was a "pro" feature, of which there
seems to be no easy way to obtain it. You need a call to action and an
automated process.

------
the_duke
Anyone here who tried out gRPC or is using it in production, and can share
some experiences?

~~~
vtalwar
caveat: I work in gRPC team. read target blogpost link to get a sense of
experience of some of the companies.
[https://cloudplatform.googleblog.com/2016/08/gRPC-a-true-
Int...](https://cloudplatform.googleblog.com/2016/08/gRPC-a-true-Internet-
scale-RPC-framework-is-now-1-and-ready-for-production-deployments.html)

~~~
rakoo
So gRPC evolved out of Stubby. An excellent show of force would be to announce
that Stubby has been internally replaced by gRPC, so that the "gRPC is
internet scale" assertion can be more than just a gimmick. Knowing nothing of
the first one and very little of the second I imagine it would be some
important task, so I have to ask: do you plan to internally run with the stuff
you open-sourced ? What is missing ?

~~~
honkhonkpants
gRPC faces a longer road to feature parity with Stubby. For external adopters
this is not an issue, so it makes sense that it would be available to the
public in advance of its adoption inside Google.

~~~
philsnow
not to mention the internal infra grows all these knobbly bits as one-off
feature requests for large/influential teams, that aren't necessarily useful
outside the goog

------
arielhn
Was looking at RPC framework for a project, in the end I went with Apache
Thrift since at that time there was no Python 3 support for gRPC [1]. IIRC
Thrift also lacks support for my project's Python version (3.5) but at least I
can use thriftpy [2].

[https://github.com/grpc/grpc/issues/282](https://github.com/grpc/grpc/issues/282)
[https://github.com/eleme/thriftpy](https://github.com/eleme/thriftpy)

~~~
hsaliak
We put in a lot of work to make gRPC work well with python 3.5, so give it a
try if possible. disclaimer: I work on gRPC.

~~~
arielhn
thank you, I'll look into it as soon as I can :)

------
Spiritus
Ugh, why does the Python driver use CamelCase method names?

    
    
        def GetFeature(self, request, context):
    

[http://www.grpc.io/docs/tutorials/basic/python.html](http://www.grpc.io/docs/tutorials/basic/python.html)

~~~
lobster_johnson
That's not the driver, that's just the example.

However, according to the style guide, camelcase is preferred, _and_ the
compiler is supposed to generate language-native names with the correct case
[1].

One thing the terrible years of SOAP and WSDL should have taught people is
that generated stubs are awful to use if they go against the grain of the host
language.

[1] [https://developers.google.com/protocol-
buffers/docs/style](https://developers.google.com/protocol-buffers/docs/style)

------
dang
Couple discussions from a year ago:
[https://news.ycombinator.com/item?id=10135347](https://news.ycombinator.com/item?id=10135347),
[https://news.ycombinator.com/item?id=9114748](https://news.ycombinator.com/item?id=9114748).

------
gshx
This looks very good. At the moment, for the jvm, there are not a lot of
features above simply building services using netty and the
protobufdecoder/encoder. Similarly, http2 goodness is also already available
in netty.

------
Spiritus
I would like to use gRPC, unfortunately the Python driver is incompatible with
Gevent[1]. And that's more or less a show stopper for us.

[1]
[https://github.com/grpc/grpc/issues/4629](https://github.com/grpc/grpc/issues/4629)

------
bastijn
Would it be worth it to use protocol buffers just for the serialization. To
replace a current traditional variant. So not for small http communication but
for larger persistent storage. Does it help for versioning purposes and
preparing for the future when your product might go from traditional to web.
Performance aside, it's a clear win there. It seems you have some overhead
against in-code solutions (separate .proto files) but it may pay off in
versioning and future of your product given all movements to Web etc.

------
fsaintjacques
What's missing to get client/server stub in pure C?

~~~
vtalwar
gRPC core libraries for C++ are written in pure C. We need to extend these to
use a pure C implementation of Proto and create a C based generated API. We
have experimented with this and some users have also tried it. We are looking
to add this in future and also welcome contributions.

------
mkvalor
Any plans for rust lang bindings?

~~~
vtalwar
would love community contributions :-). I see some efforts in community but
nothing very concrete yet. You can suggest project in gRPC Ecosystem.
[https://github.com/grpc-ecosystem](https://github.com/grpc-ecosystem)

~~~
erickt
One rust crate that seems fairly well along is
[https://github.com/stepancheg/grpc-rust](https://github.com/stepancheg/grpc-
rust). It claims it can communicate with the go client.

------
lyschoening
Any people using gRPC and Protocol Buffers from Python with good experiences?

The library for Python for one seems very unpythonic to me, starting with all
those CamelCase method names. It does not seem possible to use asyncio or any
other non-blocking solution on the server.

Finally, gRPC obviously only handles the transport: Are there any other useful
related Python packages out there for validation etc.?

------
mkvalor
Any plans for rust lang bindings? (would prefer to avoid FFI to c++)

~~~
erickt
Check out [https://github.com/stepancheg/grpc-
rust](https://github.com/stepancheg/grpc-rust). Still in development.

------
dleslie
> Or go straight to Quick Start in the language of your choice:

No plain-old-C?

That's a shame.

------
vigilant
Is gRPC a full fledged server for API calls?

e.g.: Will it have things like monitoring (we've handled x calls to this API
in the last hour, the average API call took y milliseconds). Clustering? (a
client connects to a list of grpc servers, if one server goes down, the client
will automatically connect to the next on the list)? And load balancing?

If not, are there existing third party tools to implement these, or is the
expectation that the community will create these?

~~~
honkhonkpants
As for monitoring, grpc is hooked into census, which provides some rudimentary
statistics and is also intended to eventually exfiltrate Dapper tracing out of
Google and into the public gRPC user base. It's a bit rudimentary at the
moment, but see
[https://github.com/grpc/grpc/tree/master/src/core/ext/census](https://github.com/grpc/grpc/tree/master/src/core/ext/census)

------
shanemhansen
Is "internet scale" the new "web scale"?

~~~
packetslave
"internet scale" is something of a term of art at Google. It's generally used
to mean "scales to build systems that do things like 'search the entire
contents of the Internet'"

------
tokenizerrr
So how does service discovery work? Where do I read more?

~~~
talideon
That's really an orthogonal concern. You could use Consul, DNS, &c. to do
that.

~~~
spullara
It isn't really that orthogonal. Just like authentication, things like service
discovery, smart clients (with load balancing, retries, etc) should likely be
pluggable with some reasonable defaults, otherwise you will be building your
own custom stuff on top of it and lose a lot of the value of having a
standard. See Finagle for a more complete RPC framework.

------
jadbox
How does this compare to something like zeroMQ?

~~~
guiye
I think that it's a mix betweeen ZMQ and Thrift

~~~
mns06
One big advantage of gRPC over ZeroMQ is that HTTP/2 can traverse firewalls
and proxies more easily.

------
wslh
The last time I tried gRPC with Python in Windows it didn't compile out of the
box.

~~~
kpayson64
With the 1.0.0 release, there are Windows binaries for all supported Python
versions (2.7, 3.4, 3.5). Make sure you upgrade to the latest version of Pip
before trying to pip install grpcio. (The binaries use some ABI tags that are
only recognized by newer versions of pip)

~~~
wslh
Thanks! it works now.

------
spraak
Can anyone explain like I'm 5 what an RPC framework is?

~~~
hnbroseph
whenever you hit a json api, that's effectively an RPC call.

for example, if you visit:
[https://api.github.com/repos/grpc/grpc/issues](https://api.github.com/repos/grpc/grpc/issues)

you'll get some json back. what happens is the browser resolves
"api.github.com" (via DNS) to an IP address, and then opens a socket
connection to that address. then, in accordance with the HTTP protocol it
executes a "GET" operation (a notion particular to HTTP), and in response the
github server will talk to a database or cache and respond with data
appropriate to request.

because this sequence of events happens across network boundaries (ie, your
browser is talking to something outside your computer), it's often referred to
as a "remote" procedure call.

~~~
wanghq
JSON API != RPC

Also the github api is more RESTful than RPC.

------
ungzd
> gRPC can help make connecting, operating and debugging distributed systems
> as easy as making local function calls

Oh lol, again

------
raspasov
Can someone explain how is GRPC significantly better than WebSockets? I have
used it for a few weeks and was very underwhelmed by it.

~~~
euyyn
What is your use case, and what issues did you find?

~~~
raspasov
Incomplete or completely lacking documentation for Objective C and Java, weird
bugs, random disconnects. Overall it feels like the Ruby on Rails of
networking - an opinionated package/framework that tries to do too much. Also,
the whole concept of "as easy as a a local functional call" is a flawed, leaky
abstraction.

~~~
euyyn
I'm responsible for the Objective-C part, so please let me know of anything we
can improve there. We have a couple of tutorials at
[http://www.grpc.io/docs/tutorials/](http://www.grpc.io/docs/tutorials/) and a
quick-start guide at
[http://www.grpc.io/docs/quickstart/objective-c.html](http://www.grpc.io/docs/quickstart/objective-c.html)
. For bugs and connectivity problems, filing a GitHub issue would be super
appreciated.

If you look at the example code, you'll see that RPCs aren't modeled _exactly_
as local function calls. You're right that that wouldn't work very well. The
libraries for all or most languages let you make RPCs asynchronously, without
blocking the thread. And all of them provide with ways to write and read RPC
metadata (headers and trailers).

