Google Releases gRPC 1.0, an Internet-Scale Production-Ready RPC Framework

Google has announced the release of gRPC 1.0, a highly scalable open source universal RPC Framework. gRPC version 1.0 is the first general availability (GA) release of gRPC and can be considered ready for production deployments. gRPC is designed to handle scenarios related to building, managing, and debugging loosely coupled systems at internet scale. For example, gRPC can be used to connect polyglot services in microservices architectures, connect mobile devices and browser clients to backend services, and generate client libraries.

gRPC is based on Stubby, a single general-purpose RPC infrastructure used by Google for about fifteen years to connect the numerous microservices deployed within and across Google’s datacenters. According to the announcement post, the core RPC layer of the Stubby RPC framework can handle "tens of billions of requests per second." Google has made its Stubby technology available as part of an open source project called gRPC. The goal of the project is to help developers and platform development teams efficiently build internet-scale distributed systems that are applicable to mobile, IoT, and cloud use cases.

gRPC features client libraries in C/C++, Node.js, Ruby, Python, Go, Java, and other languages that can be used across Linux, Windows and Mac. The version 1.0 release features libraries for iOS and Android (Objective-C and Android Java) and single line installation for most languages. gRPC also features bi-directional streaming with http/2 based transport, distributed tracing, authentications, load balancing, and more.

There has been some discussion about the release of gRPC 1.0 on Hacker News. Many of the comments mention that performance is one of the key benefits of using gRPC. gRPC can be used to build performance-oriented Web applications; applications that continue to perform well even at internet scale. gRPC uses Google protocol buffers, a mechanism for serializing structured data that is language and platform neutral. According to the documentation, using Google protocol buffers instead of XML for serializing structured has many advantages. For example, protocol buffers are simpler, faster, and smaller than XML.

"We are thrilled about gRPC for two reasons. (1) One is the performance and scaling improvements that we have seen in projects like etcd once clients begin using gRPC over REST. (2) Another is as gRPC uses protobuf to define the structure of APIs, it is really easy to extend that structured data to REST and OpenAPI format," Brandon Philips, CTO of CoreOS, told ProgrammableWeb. "At CoreOS, we use this approach in our projects so they can remain available to any language or framework that can consume a REST API."

Manik Surtani, software engineer at Square, told ProgrammableWeb that "Collectively, the software industry has built many custom RPC frameworks to address the shortcomings of REST. That wheel's been reinvented many, many times over. Hopefully gRPC will be the end of that pattern - a modern, strongly typed, polyglot, high-performance RPC framework that's built on open standards (HTTP/2) and is open source, backed by a vibrant community."

For more information about the gRPC open source universal RPC Framework, visit http://www.grpc.io.

Janet Wagner is a technical writer and contributor to ProgrammableWeb covering breaking news, in-depth analysis, and product reviews. She specializes in creating well-researched, in-depth content about APIs, machine learning, deep learning, computer vision, analytics, GIS/maps, and other advanced technologies.

Comments

Comments(1)

jhill5

Thank you for your very informative article. 

I am fascinated to learn that "Google protocol buffers instead of XML for serializing structured has many advantages. For example, protocol buffers are simpler, faster, and smaller than XML." 

Much is in the works of moving to HTTP/2 and I value on-going helpful insights on the topic. 

If you are so inclined, your perusal and comments on learning structured data are welcome.