gRPC

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?
    gRPC outperforms REST on many metrics. Source: Howden 2017, slide 41.
    gRPC outperforms REST on many metrics. Source: Howden 2017, slide 41.

    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?
    Language and platform agnostic gRPC requests and responses. Source: Janakiram MSV 2016.
    Language and platform agnostic gRPC requests and responses. Source: Janakiram MSV 2016.

    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 that glues the apps with the transport layer below. Source: Pai 2016, slide 18.
    gRPC is the framework that glues the apps with the transport layer below. Source: Pai 2016, slide 18.

    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?
    A typical gRPC development workflow for developers. Source: Jain 2017.
    A typical gRPC development workflow for developers. Source: Jain 2017.

    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?
    grpc-gateway generates a reverse-proxy server which translates a RESTful JSON API into gRPC. Source: grpc-ecosystem GitHub 2018.
    grpc-gateway generates a reverse-proxy server which translates a RESTful JSON API into gRPC. Source: grpc-ecosystem GitHub 2018.

    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?
    Performance of gRPC/Protobuf vs HTTP1.1/JSON. Source: Adapted from Schapira and Sethuraman 2016.
    Performance of gRPC/Protobuf vs HTTP1.1/JSON. Source: Adapted from Schapira and Sethuraman 2016.

    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.

Sample Code

  • // Source: https://grpc.io/docs/guides/concepts.html
 
// Defining a service
service HelloService {
  rpc SayHello (HelloRequest) returns (HelloResponse);
}
 
 
// Defining messages
message HelloRequest {
  string greeting = 1;
}
 
message HelloResponse {
  string reply = 1;
}
 
 
// Defining RPC methods
// Unary
rpc SayHello(HelloRequest) returns (HelloResponse){
}
 
// Server streaming
rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse){
}
 
// Client streaming
rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse) {
}
 
// Bidirectional streaming
rpc BidiHello(stream HelloRequest) returns (stream HelloResponse){
}
 

References

  1. Athaydes, Renato. 2018. "The return of RPC - or how REST is no longer the only respectable solution for APIs." Google Sites, March 4. Accessed 2018-06-01.
  2. Belshe, M., R. Peon, and M. Thomson, ed. 2015. "RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)." IETF. May. Retrieved 2017-02-16.
  3. Bernstein, Michael. 2014. "5 Reasons to Use Protocol Buffers Instead of JSON For Your Next Service." Code Climate, June 5. Accessed 2018-06-01.
  4. Bryant, Daniel. 2017. "Cloud Native Computing Foundation (CNCF) Adds Linkerd, gRPC, and CoreDNS to Growing Portfolio." InfoQ, March 25. Accessed 2018-06-02.
  5. Burks, Tim. 2017. "OpenAPI and gRPC Side-by-Side." APIs and Digital Transformation, Apigee Blog, November 06. Accessed 2018-06-01.
  6. Costa, Ciro S. 2018. "Sending files via gRPC." OpsTips Blog, January 2. Accessed 2018-06-01.
  7. Google Cloud Docs. 2018. "Transcoding HTTP/JSON to gRPC." Cloud Endpoints with gRPC, Google Cloud, April 4. Accessed 2018-06-01.
  8. Google Developers. 2017. "Protocol Buffers: Frequently Asked Questions." Google Developers, May 12. Accessed 2018-06-01.
  9. Google GitHub. 2017. "CHANGES.txt." protobuf, Google GitHub, December 21. Accessed 2018-06-01.
  10. Howden, David. 2017. "gRPC: A high performance, modern RPC system." APIDays 2017 via Google Docs, Sajari. Accessed 2018-06-01.
  11. Jain, Akshit. 2017. "Inter-Service Communication with gRPC -- Chapter 1." Medium, September 24. Accessed 2018-06-01.
  12. Janakiram MSV. 2016. "Google's gRPC: A Lean and Mean Communication Protocol for Microservices." The New Stack, September 09. Accessed 2018-06-01.
  13. LeClaire, Nathan. 2017. "What's in a transport layer?" O'Reilly Media, September 19. Accessed 2018-06-01.
  14. Lee, Gyu-Ho. 2015. "etcd: distributed key-value store with grpc/http2." Gopher Academy Blog, December 29. Accessed 2018-06-01.
  15. Marculescu, Mugur. 2015. "Introducing gRPC, a new open source HTTP/2 RPC Framework." Google Developers Blog, February 26. Accessed 2018-06-01.
  16. Nottingham, Mark. 2015. "HTTP/2 Approved." IETF Blog. February 17. Retrieved 2017-02-16.
  17. Pai, Vijay. 2016. "gRPC Design and Implementation." Stanford Platform Lab Seminar, Google Cloud Platform, April. Accessed 2018-06-01.
  18. Punnen, Alex. 2017. "REST is not the Best for Micro-Services GRPC and Docker makes a compelling case." Hacker Noon, June 08. Accessed 2018-06-01.
  19. Roche, Chris. 2018. "gRPC at Lyft." Accessed 2018-06-02.
  20. Runde, Joe and Michael Keeling. 2018. "From REST to gRPC: An API Evolution Story." IBM. Accessed 2018-06-01.
  21. Ryan, Louis. 2015. "gRPC Motivation and Design Principles." gRPC Blog, September 8. Accessed 2018-06-01.
  22. Sandoval, Kristopher. 2017. "Exploring The gRPC Framework for Building Microservices." Nordic APIs, June 27. Accessed 2018-06-01.
  23. Schapira, Emilio and Kailash Sethuraman. 2016. "Announcing gRPC Alpha for Google Cloud Pub/Sub." Google Cloud Big Data and Machine Learning Blog, March 22. Accessed 2018-06-01.
  24. Smith, Jason. 2017. "Introduction to gRPC." Container Solutions, March 01. Accessed 2018-06-01.
  25. Sookocheff, Kevin. 2017. "Comparing Swagger with Thrift or gRPC." February 9. Accessed 2018-06-02.
  26. Szelei, Tamás. 2017. "Benchmark and comparison of RPC solutions - part 1." Source Code Tales, March 10. Accessed 2018-06-01.
  27. Talwar, Varun. 2016. "gRPC Project is now 1.0 and ready for production deployments." gRPC Blog, August 23. Accessed 2018-06-01.
  28. gRPC Docs. 2018. "gRPC Documentation." May 21. Accessed 2018-06-01.
  29. gRPC GitHub. 2018. "grpc repositories." GitHub. Accessed 2018-06-01.
  30. grpc-ecosystem GitHub. 2018. "grpc-gateway." May 30. Accessed 2018-06-01.
  31. loppers92. 2017. "gRPC in Production." Hacker News, YCombinator. Accessed 2018-06-01.

Further Reading

  1. Ibinson, Ben. 2018. "Building scalable microservices with gRPC." Bugsnag Blog, January 31. Accessed 2018-06-01.
  2. gRPC Docs. 2018. "gRPC Documentation." May 21. Accessed 2018-06-01.
  3. Bernstein, Michael. 2014. "5 Reasons to Use Protocol Buffers Instead of JSON For Your Next Service." Code Climate, June 5. Accessed 2018-06-01.
  4. Burks , Tim. 2017. "OpenAPI and gRPC Side-by-Side." APIs and Digital Transformation, Apigee Blog, November 06. Accessed 2018-06-01.

Article Stats

Author-wise Stats for Article Edits

Author
No. of Edits
No. of Chats
DevCoins
User avatar hemanthSK
3
0
3264
Avatar of user mohanjo mohanjo
1
0
42
Avatar of user arvindpdmn arvindpdmn
2
0
29
Avatar of user devbot5S devbot5S
1
0
7
DevCoins due to articles, chats, their likes and article hits are included.
2133
Words
4
Authors
7
Edits
0
Chats
10
Likes
25K
Hits

Cite As

Devopedia. 2022. "gRPC." Version 7, February 15. Accessed 2023-11-12. https://devopedia.org/grpc
Contributed by
4 authors

Last updated on
2022-02-15 11:48:38
data microservices data serialization rpc

See Also