What is RPC? gRPC Introduction.

Aug 14, 2023

What is RPC? gRPC Introduction.

To get better at system design, subscribe to our weekly newsletter: https://bit.ly/3tfAlYD

Checkout our bestselling System Design Interview books:
Volume 1: https://amzn.to/3Ou7gkd
Volume 2: https://amzn.to/3HqGozy

HTTP/1 to HTTP/2 to HTTP/3:
• HTTP/1 to HTTP/2 to HTTP/3

ABOUT US:
Covering topics and trends in large-scale system design, from the authors of the best-selling System Design Interview series.

Content

7.642 -> What is gRPC?

8.94 -> When should we use it?

10.14 -> Let’s take a look.

12 -> gRPC is an open-source remote procedure call framework created by Google in 2016.

17.28 -> It was a rewrite of their internal RPC infrastructure that they used for years.

22.2 -> But first, what is an RPC, or a remote procedure call?

27.48 -> A local procedure call is a function call within a process to execute some code.

32.58 -> A remote procedure call enables one machine to invoke some code on another machine as

37.86 -> if it is a local function call from a user’s perspective.

42.18 -> gRPC is a popular implementation of RPC.

45.66 -> Many organizations have adopted gRPC as the preferred RPC mechanism to connect a large

52.2 -> number of microservices running within and across data centers.

56.94 -> What makes gRPC so popular?

58.62 -> Let’s dive a little deeper.

61.08 -> First, gRPC has a thriving developer ecosystem.

64.62 -> It makes it very easy to develop production-quality

68.34 -> and type-safe APIs that scale well.

71.88 -> The core of this ecosystem is the use of Protocol Buffers as its data interchange format.

78.18 -> Protocol Buffers is a language-agnostic and

81.3 -> platform-agnostic mechanism for encoding structured data.

85.32 -> gRPC uses Protocol Buffers to encode and send data over the wire by default.

90.96 -> While gRPC could support other encoding formats like JSON,

94.56 -> Protocol Buffers provide several advantages that make it the encoding format of choice for gRPC.

102.06 -> Protocol Buffers support strongly-typed schema definitions.

105 -> The structure of the data over the wire is defined in a proto file.

110.64 -> Protocol Buffers provide broad tooling support to turn the schema defined in

115.44 -> the proto file into data access classes for all popular programming languages.

120.96 -> A gRPC service is also defined in a proto file by specifying RPC method parameters and return types.

129.42 -> The same tooling is used to generate gRPC client and server code from the proto file.

135.3 -> Developers use these generated classes in the client to make RPC calls,

140.28 -> and in the server to fulfill the RPC requests.

144.36 -> By supporting many programming languages, the client and server can independently choose

149.58 -> the programming language and ecosystem best suited for their own particular use cases.

154.38 -> This is traditionally not the case for most other RPC frameworks.

160.26 -> The second reason why gRPC is so popular is because it is high-performance out of the box.

166.38 -> Two factors contribute to its performance.

169.56 -> First is that Protocol Buffers is a very efficient binary encoding format.

174.6 -> It is much faster than JSON.

177.36 -> Second, gRPC is built on top of HTTP/2 to provide a high-performance foundation at scale.

184.8 -> The use of HTTP/2 brings many benefits.

187.5 -> We discussed HTTP/2 in an earlier video.

190.56 -> Check out the link in the description for more information.

194.52 -> gRPC uses HTTP/2 streams.

197.16 -> It allows multiple streams of messages over a single long-lived TCP connection.

202.74 -> This allows the gRPC framework to handle many concurrent RPC calls over a small number of

208.62 -> TCP connections between clients and servers.

212.16 -> To understand how gRPC works, let’s walk through a typical flow from a gRPC client to a gRPC server.

220.38 -> In this example, the Order Service is the gRPC client,

224.16 -> and the Payment Service is the gRPC server.

227.76 -> When the Order Service makes a gRPC call to the Payment Service,

231.24 -> it invokes the client code generated by gRPC tooling at build time.

235.86 -> This generated client code is called a client stub.

240.42 -> gRPC encodes the data passed to the client stub

243.42 -> into Protocol Buffers and sends it to the low-level transport layer.

248.28 -> gRPC sends the data over the network as a stream of HTTP/2 data frames.

253.56 -> Because of binary encoding and network optimization,

256.5 -> gRPC is said to be 5 times faster than JSON.

261.06 -> The payment service receives the packets from

263.28 -> the network, decodes them, and invokes the server application.

268.44 -> The result returned from the server application

270.72 -> gets encoded into Protocol Buffers and sent to the transport layer.

275.34 -> The Order Service receives the packets, decodes them,

278.22 -> and sends the result to the client application.

281.52 -> As we see from the example above, gRPC is very easy to implement.

286.08 -> If it is so easy, why do we not see wide-spread use of gRPC between web clients and web servers?

293.22 -> One reason is that gRPC relies on lower-level access to HTTP/2 primitives.

298.32 -> No browsers currently provide the level of control

301.62 -> required over web requests to support a gRPC client.

306.54 -> It is possible to make gRPC calls from a browser with the help of a proxy.

312 -> This technology is called gRPC-Web.

314.76 -> However, the feature set is not fully compatible with

318.54 -> gRPC and its usage remains low compared to gRPC.

324.18 -> So, where does gRPC shine, and when should we use it?

327.78 -> gRPC is the inter-service communication mechanism of

330.84 -> choice between microservices in the data centers.

333.72 -> Its broad support for many programming languages allows services to choose their

338.64 -> own language and developer ecosystems best suited for their own use cases.

344.22 -> We also see increasing use of gRPC in the native mobile clients.

349.02 -> Its efficiency and performance makes a lot of sense in the

352.8 -> energy- and bandwidth-constrained environments that are mobile devices.