
GRPC: A high performance, open source, general RPC framework - chuhnk
http://www.grpc.io/
======
necubi
It's a bit buried in the announcement, but this is also using a new version of
protobuf [0] (3.0) which fixes a number of long-standing complaints about the
format:

    
    
        * No more required fields
        * Now supports maps (a huge pain point)
        * A canonical json encoding
        * Wider official language support
    

[0]
[https://github.com/google/protobuf/releases](https://github.com/google/protobuf/releases)

~~~
justinsb
Personally, I'm very disappointed that we've lost immutability, along with
support for nullable fields (e.g. Protobuf3 now assumes that 0 == null).

~~~
ejona86
Immutability is still there. You get to choose whether you want it or not.

For when you actually want a nullable field, I think the idea is that it is
easy to have a wrapper message (just like boxing in languages). Such wrappers
could even be made standard and provided by protobuf.

~~~
haberman
> Such wrappers could even be made standard and provided by protobuf.

They will be:
[https://github.com/google/protobuf/issues/159#issuecomment-7...](https://github.com/google/protobuf/issues/159#issuecomment-76240356)

------
estefan
This is what I've been looking for! Generated code on a production quality
server (Netty), with no faffing around with JSON, etc. It would be sweet to
see that Java server ported to scala though (or some docs to show me how to
plug scala into the Java server), and also front-end javascript clients (I saw
that was a work-in-progress).

If this would work with juniversal[0], and if that's actually any good, then
this might actually give a quick way of churning out cross-platform apps.

[0][http://juniversal.org/](http://juniversal.org/)

~~~
pacala
+1. I'd been looking for a while for a production quality RPC solution,
especially one with Scala bindings.

Regarding the gRPC release, I've looked at the examples in the repo and only
found this: [https://github.com/grpc/grpc-java/tree/master/integration-
te...](https://github.com/grpc/grpc-java/tree/master/integration-
testing/src/main/java/io/grpc/testing/integration). While it's a great
showcase for the power of gRPC, having a "hello world" example with,
hopefully, not a whole lot of boilerplate, would help a lot selling this to my
team.

~~~
ejona86
The Java examples are in the examples folder: [https://github.com/grpc/grpc-
java/tree/master/examples/src/m...](https://github.com/grpc/grpc-
java/tree/master/examples/src/main/java/io/grpc/examples)

The examples folder references a tutorial at [https://github.com/grpc/grpc-
common/blob/master/java/javatut...](https://github.com/grpc/grpc-
common/blob/master/java/javatutorial.md)

------
chuhnk
Shedding more light on this.
[http://googledevelopers.blogspot.co.uk/2015/02/introducing-g...](http://googledevelopers.blogspot.co.uk/2015/02/introducing-
grpc-new-open-source-http2.html)

------
cespare
What HTTP/2 features make it desirable for general RPC (no browser involved)?

In the past I've found HTTP (1.1) to be okay, but not great for server->server
RPC. The semantics are fine (but overkill) and the overhead sort of sucks.
With HTTP/2 I guess the performance should be a lot better (with a binary
protocol); I'm still unsure about the HTTP semantics in a general RPC context.
Anyone with deeper knowledge of HTTP/2 care to enlighten me?

(Following up on a twitter conversation I had with @bradfitz:
[https://twitter.com/calebspare/status/571049339541270529](https://twitter.com/calebspare/status/571049339541270529))

~~~
a11r
gRPC uses the following features from HTTP/2: Framing (needed to multiplex
different RPCs on the same TCP connection), Flow Control (both intra-stream
and connection-wide), HPAC (for compressing metadata that tends to be common
across requests), and GoAway (to gracefully drain backends).

~~~
cespare
Thanks! This is a good list.

------
nostrademons
Curious how this compares to Capn'Proto? Speed differences? Any functionality
that's in one that's not in the other?

~~~
louiscryan
This is an interesting an complex topic.

Kenton does a pretty good job discussing this here
[https://capnproto.org/news/2014-06-17-capnproto-
flatbuffers-...](https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-
sbe.html)

and rightly mostly focuses on the message-encoding aspects. Performance will
vary by use-case & platform and should be traded off against the suitability
for the given use-case (platform support, schema evolution, fidelity of
representation, maturity vs bleeding edge)

Cap'N'Proto has some interesting RPC features (promise-pipelining, pass-by-
reference) that may be valuable to some.

FYI it would be perfectly reasonable to use Cap'N'Proto messages with GRPC as
the transport layer to get HTTP2 support. GRPC was explicitly designed to
allow for this.

Protobuf has better platform coverage than FlatBuffers and it's schema is
easier to evolve but neither of these may matter for your use-case. As in all
things it depends.

------
taspeotis

        Automatically generate idiomatic client and server
        stubs for your service in a variety of languages.
    
        gRPC has libraries in ... C# [0]
    

Aweso-

    
    
        This gRPC C# implementation is work-in-
        progress and is not expected to work yet.
    

[0]
[https://github.com/grpc/grpc/tree/master/src/csharp](https://github.com/grpc/grpc/tree/master/src/csharp)

------
maniksurtani
And more details
[http://corner.squareup.com/2015/02/grpc.html](http://corner.squareup.com/2015/02/grpc.html)

------
tmzt
Awesome, now they can get to work on making the security portions of QUIC the
basis for SSL 2.0 with PFS, EC and SSH like fingerprinting with user agent
pinning, as well as multi-tiered CA (so a CA can only sign certs for a certain
domain) and something resembling DANE but without the mandatory DNSSEC
dependency.

------
rdtsc
There seems to be a semantic overlap between streaming data with HTTP/2 vs
streaming websocket frames back and forth.

Does this have a distinct advantage over websockets, does it supersede it or
is completely different?

To put it another way, could gRPC have worked via websockets (or maybe some
long-polling fallback mode).

~~~
louiscryan
HTTP2 is superior to WebSocket at the transport layer because it adds explicit
framing support and other things. Websocket-over-HTTP2 is coming, but it's not
here now.

While HTTP/1.1 was a poor transport for high-perf RPC there are many parts of
it that make sense semantically (headers, trailers, mime-types, virtual-
hosting, content-encoding specification etc). HTTP2 lets you continue to use
those in a form everyone is familiar with, with Websocket you would have to
invent them again.

~~~
Matthias247
Does HTTP2 have guarantees that the connection is really reused for multiple
requests or could a user agent (or HTTP library) silently use multiple
connections for different requests?

I think this makes a major difference for RPC applications, because with a
single connection you have a guarantee that all messages will be retrieved in
the same order that they were sent.

E.g. with a persistent websocket connection I have the guarantee that all
messages will be in order. With mulitple HTTP/1.1 requests I don't have it.
Don't know about HTTP/2.

And of course the requirements about such a thing depend on how you design
your RPC API (stateless or not).

~~~
ejona86
HTTP/2 has the concept of streams. Each stream is independent, but within a
stream data and headers are ordered. Each HTTP request would be on a new
stream.

gRPC maps calls to streams so calls can proceed at different rates, but you
still receive the information on a particular call in order. So conceptually
each call is completely separate, but we can use a single HTTP/2 connection
for all the calls to a particular destination.

------
rektide
It's a little hard for me to understand what if anything this presents. At
first I thought perhaps Protocol Buffers didn't have an RPC layer, and that
this was bringing Protocol Buffers up to a comparable level of competitors
like Thrift. Checking the Protocol Buffers docs though, I see they do already
have services.

Is this simply a consistent, cross-language looking interface for
authoring/consuming Protocol Buffers services? What makes this different from
other Protocol Buffer implementations?

~~~
haberman
Just to add to a11r's comment:

\- this is not a new Protocol Buffer implementation. It uses the existing
Protocol Buffers implementation for serialization/deserialization.

\- this is actual implementation for the service declarations you could write
in .proto files already (previously Protocol Buffers could only generate
interface stubs, without implementation).

------
wbsun
What are the benefits of using HTTP rather than TCP directly? I guess one of
them is easy to pass firewalls. Anything else makes HTTP better than raw TCP
for RPC?

~~~
somethingnew
Not having to worry about calculating the length of the message before
transferring it?

~~~
ejona86
gRPC actually still has to calculate the length of a message before
transferring it.

------
ChuckMcM
This is great, but the asymmetry here is not. Specifically, if you are a
company and you use this and contribute to it, you have to sign this license:
[https://cla.developers.google.com/clas/new?kind=KIND_CORPORA...](https://cla.developers.google.com/clas/new?kind=KIND_CORPORATE&domain=DOMAIN_GOOGLE)

Which has these clauses:

 _Grant of Copyright License. Subject to the terms and conditions of this
Agreement, You hereby grant to Google and to recipients of software
distributed by Google a perpetual, worldwide, non-exclusive, no-charge,
royalty-free, irrevocable copyright license to reproduce, prepare derivative
works of, publicly display, publicly perform, sublicense, and distribute Your
Contributions and such derivative works.

Grant of Patent License. Subject to the terms and conditions of this
Agreement, You hereby grant to Google and to recipients of software
distributed by Google a perpetual, worldwide, non-exclusive, no-charge,
royalty-free, irrevocable (except as stated in this section) patent license to
make, have made, use, offer to sell, sell, import, and otherwise transfer the
Work, where such license applies only to those patent claims licensable by You
that are necessarily infringed by Your Contribution(s) alone or by combination
of Your Contribution(s) with the Work to which such Contribution(s) was
submitted. If any entity institutes patent litigation against You or any other
entity (including a cross-claim or counterclaim in a lawsuit) alleging that
your Contribution, or the Work to which you have contributed, constitutes
direct or contributory patent infringement, then any patent licenses granted
to that entity under this Agreement for that Contribution or Work shall
terminate as of the date such litigation is filed._

But Google doesn't grant you the same perpetual right to use and patent
licenses back to you if you use gRPC. So I worry that if I start using this
code, and Google decides to pull it, they can, even if some of it came from
work that I did on it.

Now before someone says "But Chuck, they wouldn't do that ..." I want to
remind you that licenses and contracts are not written to cover the 'good'
time where everyone likes everyone, they are written to cover the 'bad' time
when for one reason or another (often entirely unrelated to a particular API)
that people stop liking each other so much.

The fix is simple however, Google could put in their license just a bit of
additional text, which replaces

"Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:"

With

"Redistribution, use, and sub-licensing for this code in source or binary
form, with or without modification, is granted, without cost, non-exclusively,
and in perpetuity, provided the following conditions are met:"

Is there someone from the project reading this that can get that wording
updated?

~~~
DannyBee
1\. These clauses are actually not ones we wrote, they are from the Apache
CCLA, widely used across the industry :)

2\. "But Google doesn't grant you the same perpetual right to use and patent
licenses back to you if you use gRPC"

Sorry, this was actually just human error.

They forgot to add the file I gave them.

I'll get it added to the repository post-haste.

(The patent grant is identical to the Go one)

~~~
Mugurm
We've just added the Patent Grant to all the repos. Thanks for pointing this
out.

------
otterley
How does performance compare to XDR and ONC/RPC?

------
anoncoder
Can anyone find benchmarks? I can't spend much time looking at it unless they
back up their claims.

~~~
a11r
Benchmarks are under development: you can see the code in
[https://github.com/grpc/grpc/tree/master/test/core/fling](https://github.com/grpc/grpc/tree/master/test/core/fling)
and
[https://github.com/grpc/grpc/tree/master/test/cpp/qps](https://github.com/grpc/grpc/tree/master/test/cpp/qps)
.

------
rust101_noob
How is concurrency handled in this RPC server for blocking operations?

~~~
ejona86
It varies based on language: some languages use async callbacks, some use
futures/promises, some block and require threads, and some support multiple
forms. The intent is that programmers in that language would handle
concurrency however they would normally handle concurrency.

------
billowqiu
exicting

------
easytiger
> A High performance

> Define your service using Protocol Buffers,

Erm...

------
halayli
If you are advertising it as a high performance RPC, you shouldn't be using
protobufs.

Cap'n proto and flatbuffers are much faster.

~~~
ejona86
When people might be comparing it to REST with JSON, it is fast.

gRPC can be used with flatbuffers and similar. The experience has been
targeting protobufs, but at its core it just expects a serialized message.
Other formats can be made to work with relatively low effort. So if protobuf
is the issue, try swapping to your favorite marshaller.

