What is gRPC? When should we use it? Let’s take a look. gRPC is an open-source remote procedure call framework created by Google in 2016. It was a rewrite of their internal RPC infrastructure that they used for years. But first, what is an RPC, or a remote procedure call? A local procedure call is a function call within a process to execute some code. A remote procedure call enables one machine to invoke some code on another machine as if it is a local function call from a user’s perspective. gRPC is a popular implementation of RPC. Many organizations have adopted gRPC as the preferred RPC mechanism to connect a large number of microservices running within and across data centers. What makes gRPC so popular? Let’s dive a little deeper. First, gRPC has a thriving developer ecosystem. It makes it very easy to develop production-quality and type-safe APIs that scale well. The core of this ecosystem is the use of Protocol Buffers as its data interchange format. Protocol Buffers is a language-agnostic and platform-agnostic mechanism for encoding structured data. gRPC uses Protocol Buffers to encode and send data over the wire by default. While gRPC could support other encoding formats like JSON, Protocol Buffers provide several advantages that make it the encoding format of choice for gRPC. Protocol Buffers support strongly-typed schema definitions. The structure of the data over the wire is defined in a proto file. Protocol Buffers provide broad tooling support to turn the schema defined in the proto file into data access classes for all popular programming languages. A gRPC service is also defined in a proto file by specifying RPC method parameters and return types. The same tooling is used to generate gRPC client and server code from the proto file. Developers use these generated classes in the client to make RPC calls, and in the server to fulfill the RPC requests. By supporting many programming languages, the client and server can independently choose the programming language and ecosystem best suited for their own particular use cases. This is traditionally not the case for most other RPC frameworks. The second reason why gRPC is so popular is because it is high-performance out of the box. Two factors contribute to its performance. First is that Protocol Buffers is a very efficient binary encoding format. It is much faster than JSON. Second, gRPC is built on top of HTTP/2 to provide a high-performance foundation at scale. The use of HTTP/2 brings many benefits. We discussed HTTP/2 in an earlier video. Check out the link in the description for more information. gRPC uses HTTP/2 streams. It allows multiple streams of messages over a single long-lived TCP connection. This allows the gRPC framework to handle many concurrent RPC calls over a small number of TCP connections between clients and servers. To understand how gRPC works, let’s walk through a typical flow from a gRPC client to a gRPC server. In this example, the Order Service is the gRPC client, and the Payment Service is the gRPC server. When the Order Service makes a gRPC call to the Payment Service, it invokes the client code generated by gRPC tooling at build time. This generated client code is called a client stub. gRPC encodes the data passed to the client stub into Protocol Buffers and sends it to the low-level transport layer. gRPC sends the data over the network as a stream of HTTP/2 data frames. Because of binary encoding and network optimization, gRPC is said to be 5 times faster than JSON. The payment service receives the packets from the network, decodes them, and invokes the server application. The result returned from the server application gets encoded into Protocol Buffers and sent to the transport layer. The Order Service receives the packets, decodes them, and sends the result to the client application. As we see from the example above, gRPC is very easy to implement. If it is so easy, why do we not see wide-spread use of gRPC between web clients and web servers? One reason is that gRPC relies on lower-level access to HTTP/2 primitives. No browsers currently provide the level of control required over web requests to support a gRPC client. It is possible to make gRPC calls from a browser with the help of a proxy. This technology is called gRPC-Web. However, the feature set is not fully compatible with gRPC and its usage remains low compared to gRPC. So, where does gRPC shine, and when should we use it? gRPC is the inter-service communication mechanism of choice between microservices in the data centers. Its broad support for many programming languages allows services to choose their own language and developer ecosystems best suited for their own use cases. We also see increasing use of gRPC in the native mobile clients. Its efficiency and performance makes a lot of sense in the energy- and bandwidth-constrained environments that are mobile devices. If you would like to learn more about system design, check out our books and weekly newsletter. Please subscribe if you learned something new. Thank you so much, and we’ll see you next time.