# gRPC

## Summary


Tightly integrated monolithic applications of the past gave way to modular design. With the growth of the Internet, different parts an application could reside in different servers and accessed over the network using what we *Remote Procedure Call (RPC)*. With the advent of cloud computing, applications are composed of microservices. These microservices are loosely integrated but their interfaces are precisely defined using APIs. 

gRPC is a framework that enables the implementation of highly scalable and performant application whose parts are distributed over a network. The framework abstracts away the low-level networking details from app developers so that they can focus on the application logic. Developers need not worry about how one part calls a functionality in another remote part. gRPC takes care of this and enables more responsive real-time apps. 

**gRPC** is a recursive abbreviation that expands to **gRPC Remote Procedure Call**.

## Discussion

### How has gRPC come about?

Since the 1990s, networking has played an important part of computing infrastructure. In distributing computing, one computer can trigger an action on another remote computer. CORBA, DCOM and Java's Remote Method Invocation(RMI) were used to make this possible. As the web matured in early 2000s, RPC methodology started relying more and more on HTTP, XML, SOAP and WSDL. The idea was to use standardized technologies for interoperability regardless of languages or platforms. With Web 2.0 and cloud computing, HTTP/XML/SOAP combination was replaced with HTTP/JSON, which resulted in REST. Cloud applications were composed of microservices and these communicated via REST APIs. 

More recently, smartphones and IoT devices are invoking these microservices. These devices have limited compute power, communication bandwidth or both. In such cases, HTTP/JSON with REST is seen as an inefficient approach. gRPC solves this problem. In fact, back in 2016, within it's data centers Google made about 100 billion RPC calls per second. At that scale, Google calling REST APIs would have been inefficient. 


### What are the essential elements of gRPC?

One way to summarize gRPC is that, 

> It's a lean platform using a lean transport system to deliver lean bits of code.

**gRPC** is the platform. **HTTP/2** is the transport. **Protocol Buffers** deliver lean bits of code. Together, they reduce latency and improve efficiency. 

gRPC depends on HTTP/2. HTTP/2 supports bidirectional streaming, flow control and header compression. Moreover, multiple requests can be sent over a single TCP connection. 

When distributed parts of an application need to communicate with one another, data needs to be serialized. Protocol Buffers is used as the *Interface Definition Language (IDL)* to specify both the service interface and the structure of the payload messages. Thus, the specification is developer-friendly. In addition, data is sent on the wire in an efficient binary format. The encoding and decoding is transparent to the developer and done automatically by the framework.

gRPC is about services and messages, not objects and references. gRPC is language agnostic: developer can use any programming language. gRPC is payload agnostic: the use of Protocol Buffers is not required. gRPC provides authentication out of the box. 


### What are the benefits of using gRPC?

In the world of RESTful JSON API, there can be problems of version incompatibility: the API has changed at the server, and client is using an older version. Writing a client library along with authentication is also extra work. The use of HTTP/1.1 is also a poor fit for streaming services. Because JSON data is textual, it takes more bandwidth. It also takes more work to encode and decode JSON. 

With gRPC, both client and server code are generated by the compiler. gRPC comes with language bindings for many popular languages. The use of Protocol Buffers solves the efficiency problem of JSON. Bidirectional streaming is possible and authentication is part of the framework. 

Protobuf ensures backward compatibility and offers validations and extensibility. Protobuf provides static/strong typing that REST lacks. This minimizes the overhead of encoding. 

Compared to other RPC frameworks, gRPC speaks the language of the web (HTTP/2), comes with multiple language bindings, and therefore makes it easier for developers.


### What are the different gRPC life cycles?

gRPC life cycles include: 

    + **Unary**: This is the simplest one. When client calls a server method, server is notified with client metadata for this call, method name and deadline. Server may respond with its own metadata or simply wait for client's request message. Once request is received, server will execute the method, then send response and status code to client.
    + **Server Streaming**: Similar to the unary case, except that server sends a stream of responses.
    + **Client Streaming**: Similar to the unary case, except that the client sends a stream of requests. Server need not wait for all requests before sending a single response.
    + **Bidirectional Streaming**: This starts with a client request but subsequently client and server can read or write in any order. Each stream operates independent of the other. It's really application dependent.gRPC calls can be either synchronous or asynchronous. Since networks are inherently asynchronous, asynchronous calls are recommended so that current thread is not blocked. 


### Where does gRPC fit within the communication stack?

gRPC is the framework layer that interfaces to the transport layer below and to the application layer above. In fact, gRPC makes it easier for application developers to make RPC calls over the network since the framework abstracts away all the low-level network operations. By using HTTP/2 for transport, gRPC benefits from all the performance enhancements that HTTP/2 offers over HTTP/1.1.

Developers can write apps in any language of their choice. To ease the job of calling framework APIs, gRPC provides language bindings in many popular languages. The core of gRPC is implemented in C for performance reasons. These language bindings are therefore wrappers over the low-level C API. 

Finally, application code can be fully hand-written but it's possible to generate boilerplate code based on message definitions. For example, if we use protobuf for data serialization, the *protobuf compiler* can be used to generate request/response and client/server classes. The developer can therefore focus on writing her application to invoke the methods of these generated classes. 


### What are some myths surrounding gRPC?

Here are some myths about gRPC:

    + gRPC works with only microservices: gRPC can be used in any distributed app that needs to communicate over the network.
    + gRPC depends on protobuf: Protocol Buffers are used by default but any other suitable data serialization protocol can be used depending on specific app requirements. JSON could be useful when data must be human readable or data needs to be directly consumed by a web browser.
    + gRPC will replace REST: This may happen in future but right now both will probably coexist and even interwork. Prefer REST for interoperability and gRPC for performance. It's easy to directly consume REST APIs with tools such as curl, but gRPC tooling may improve to offer similar functionality.
    + gRPC is only for server-side communications: Web browsers can also use gRPC. grpc-web is one project that enables this.
    + gRPC core is implemented in C: C is the default implementation but there are implementations in Go, Java, Swift, Dart and JavaScript.

### If I'm developing a gRPC service, what's the recommended workflow?

First you define the service methods and data using an IDL of your choice. Protocol Buffers is one possible choice of IDL. Definitions are stored in `*.proto` files. 

The next step is to invoke the `protoc` compiler to generate code in languages of your choice. Many languages are supported as on June 2018: C++, Java, Python, Go, Ruby, C#, Node.js, Android Java, Objective-C, PHP and Dart. 

On the client side, gRPC functionality is implemented in what's called a *stub*. Your app code can call into methods of the stub along with local objects as arguments. gRPC will translate the calls to gRPC requests to the server along with binary serialized protobuf. 


### How do I migrate my REST API-based web service to gRPC?

Migrating a service to gRPC overnight might break many clients still using REST APIs. It's therefore recommended to have a transition period in which REST and gRPC services are both operational. Even in the long term, it might a good idea to redirect REST calls to gRPC. 

Project grpc-gateway is a way to generate *reverse proxy* code. grpc-gateway works as a plugin to protobuf compiler. The reverse proxy will then translate RESTful JSON API into gRPC method calls.

Within Google Cloud, transcoding HTTP/JSON to gRPC happens via what is called *Extensible Service Proxy (ESP)*. This is enabled by adding annotations in your `*.proto` files or separately in YAML files. 


### Who's been using gRPC in the real world?

gRPC has been adopted by CoreOS, Netflix, Square, Cockroach Labs and etcd. Telecom companies Cisco, Juniper, and Arista are using it for streaming telemetry data and network configurations. Docker's containerd exposes functionality via gRPC. 

Square moved from a proprietary RPC framework to gRPC and they have shared their experience on YouTube. Lyft has used gRPC along with Envoy. For some services, they used a Go implementation of gRPC. For others, they used Flask-Python with gevent, which didn't work well with gRPC. Hence, they used Envoy to bridge gRPC with HTTP/1.1 while using protobuf. 


### Could you share some performance numbers of gRPC?

A benchmark test on Google Cloud using 9 gRPC channels compared gRPC performance versus HTTP1.1/JSON. gRPC achieved 3x throughput using only a fourth of the resources. On a per CPU basis, this was 11x the HTTP1.1/JSON throughput. This improvement is due to protobuf in which data is kept and transmitted in binary without involving any Base64 or JSON encoding/decoding. In addition, HTTP/2 can multiplex requests on a single connection and apply header compression. 

Another test involving 300K requests of key/value stores in *etcd* showed that JSON took 1.6ms, single-client gRPC took 122.4µs and 100-client gRPC took 12.9µs. Memory usage per operation dropped by 44%. When comparing single-client and 100-client gRPC cases, the latter ran in one-fifth the time because multiple requests go on a single TCP connection. 

When sending files over gRPC, it's been shown that plain HTTP/2 is faster because there's no encoding or decoding; it's just raw data transmission. 


### How does gRPC compare against other RPC frameworks?

When comparing different RPC frameworks, gRPC's deserialization can be slow compared to Cap'n Proto. Within gRPC, a C++ implementation is faster than one in Java, Go or Python. It should be noted that performance depends on the message complexity. Another benchmark tests showed that gRPC isn't the fastest. Cap'n Proto, rpclib and Thrift all perform better with Cap'n Proto being the best for deeply nested message structures. This could be because gRPC forgoes zero-copy approach that Cap'n Proto or Flatbuffers use. Instead, gRPC aims to encode data for smaller bandwidth requirements at the expense of extra CPU computation. 

Thrift and gRPC both support code generation and serialization. However, Thrift doesn't use protobuf or HTTP/2. While REST+JSON API isn't RPC, Swagger is a tool that supports API design and code generation. gRPC alternatives in Java are many.

Some developers might find it useful to study the implementation of different RPC mechanisms. Developer Renato Athaydes claims that gRPC doesn't work well with JVM types and hence provides his own version of RPC based on Protocol Buffers. 

## Milestones

Jul  
2008

Initial version of **Protocol Buffers** is released. Version 1.0 of Protocol Buffers (internal to Google) inspires the design and implementation of version 2.0, often called *proto2*. Profocol Buffers are also called *protobufs*. 

Dec  
2014

Version 3.0-alpha of Protocol Buffers (*proto3*) is released. A stable version 3.0.0 is released in July 2016. This development parallels that of gRPC. 

Feb  
2015

Google releases and open sources **gRPC** based on its vast experience in building distributed systems. Google states that they're starting to expose most their public services via gRPC endpoints. gRPC uses HTTP/2. Meanwhile, Internet Engineering Steering Group (IESG) approves HTTP/2 as a proposed standard. In May 2015, HTTP/2 is published as RFC 7540. gRPC itself is influenced by Stubby, an earlier RPC framework used by Google internally. 

Aug  
2016

Google releases V1.0 of gRPC with improved usability, interoperability, and performance measurement. This version is now considered stable and production ready. Language support includes C++, Java, Go, Node, Ruby, Python and C# across Linux, Windows, and Mac; Objective-C and Android Java on iOS and Android. 

Mar  
2017

Cloud Native Computing Foundation (CNCF) adds gRPC to its portfolio. This means that CNCF will host and guide the development of gRPC.