Facilitating the spread of knowledge and innovation in professional software development



Choose your language

InfoQ Homepage News gRPC 1.0 is Ready for Production

gRPC 1.0 is Ready for Production

Leia em Português


Google has released gRPC 1.0, considering it stable and ready for production.

gRPC started as an internal Google project called Stubby, used for communication by some of their internal services. Google open sourced the framework 18 months ago with the hope that others will embrace it and use it when consuming services from Google, communicating with other services across the internet or for internal products.

gRPC is a platform-neutral RPC system that uses the Protocol Buffers IDL to define end-point services and message payloads to be transferred, then generating stubs for multiple languages. gRPC supports 10 languages - C, C++, C#, Go, Java (including Java/Android), Node.js, Objective-C, PHP, Python, and Ruby – on Linux, Mac and Windows. There are native implementations in C, Go and Java, and wrappers around the C library for the other languages. A performance dashboard was set up by Google to show the latency of various gRPC communications between two VM instances in the same datacenter. For unary synchronous secure messages, the chart shows the base Netperf results at about 100 us, while C++, Java and C# implementations are at about 200-300 us, and Ruby, Python and Node.js are at 700, 900 and respectively 1.100 us.

Messages to be transferred are serialized in a binary format using Protocol Buffers 3.0 which is meant to provide better performance than text formats. Compared to JSON, ProtoBuf can cut the size of a message in half and use a third of the time to serialize/deserialize it, according to Kelsey Hightower, a Google engineer.

Beside unary RPCs which consist of one request followed by one response, gRPC makes use of HTTP/2 to provide uni or bi-directional streaming between client and server. Communication can be synchronous or asynchronous and supports authentication via SSL/TLS or OAuth2 (with Google APIs).

The installation process has been simplified by providing gRPC binaries via CocoaPods, gem, Gradle, Maven, npm, NuGet, pecl, pip, or Docker images.

A number of companies, including Cisco, CoreOS, Juniper, Netflix and Square, are using gRPC internally, according to Google.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Dart language is not supported?

    by Andrew Mezoni,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The C based gRPC (C++, Node.js, Python, Ruby, Objective-C, PHP, C#)
    Google does not provide support of the Dart language?
    I thought it had to be done first.
    Or Dart language implemented not by the Google?

  • Re: Dart language is not supported?

    by Andrew Reed,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    gRPC is more for communicating between servers than communicating between a browser and a server, but there is an issue open in the Dart repo to support gRPC.

  • Re: Dart language is not supported?

    by Andrew Mezoni,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Do you means that Dart is suitable only for communicating between a browser and a server?

    I always thought that Dart VM designed for developing scripts and server apps.
    Information from here:

    This information does not restrict to use Dart for communicating between servers.

    Can you explain, for the uninitiated, where you found that Dart purpose is only "communicating between a browser and a server" and in any case it is not for "communicating between servers"?


    Issues of such kind Dart has a lot only because Google never provide support for Dart in any significant project such as this subject.

  • Protocol buffers just like the old days

    by Neil Murphy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    This is just an over-engineered rehash of the old mainframe file systems with a fancier name. They will be reinventing COBOL next

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p


Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.