Getting Started with gRPC

gRPC is an open source framework for general-purpose Remote Procedure Calls (RPCs) across a network. RPCs allow a remote procedure (hosted on a different machine) to call as if it were calling a local procedure in connected systems without coding the remote interaction details. RPC has a constant meaning in the gRPC abbreviation. It seems logical that the g in gRPC would refer to Google because it was initially developed there. But the meaning of the g has changed with every release. For its first release, version 1.0, the g in gRPC stood for gRPC itself. That is, in version 1.0, it stood for gRPC Remote Procedure Call. In this chapter, you are going to use gRPC version 1.54, where the g stands for gracious. Therefore, you can refer to gRPC as gracious Remote Procedure Call (for version 1.54). You can find out all the meanings of the g for different versions at https://github.com/grpc/grpc/blob/master/doc/g_stands_for.md.

In this chapter, you’ll...

Technical requirements

This chapter contains only the theory of gRPC. However, you would generally need any gRPC API client such as Insomnia for the development and testing of gRPC-based web services.

You are going to learn the fundamentals of gRPC in this chapter, so this chapter doesn’t have its own code repository. However, for actual code, you can refer to the Chapter 11 code at https://github.com/PacktPublishing/Modern-API-Development-with-Spring-6-and-Spring-Boot-3/tree/dev/Chapter11.

How does gRPC work?

gRPC is an open source framework for general-purpose RPCs across a network. gRPC supports full-duplex streaming and is also mostly aligned with HTTP/2 semantics. It supports different media formats, such as Protocol Buffers (Protobuf), JSON, XML, and Thrift. Protobuf is the default media format. The use of Protobuf aces the others because of higher performance.

gRPC brings the best of REST (Representational State Transfer) and RPC to the table and is well suited for distributed network communication through APIs. It offers some prolific features, as follows:

• It is designed for a highly scalable distributed system and offers low latency.
• It offers load balancing and failover.
• It can be integrated easily at the application layer for interaction with flow control because of its layered design.
• It supports cascade call cancellation.
• It offers wide communication — mobile app to server, web app to server, and any gRPC client app to the...

Understanding service definitions

You define a service by specifying its methods with the respective parameters and return types. These methods are exposed by the server, which can be called remotely. You defined the EmployeeService definition in the previous subsection, as shown in the next code block:

service EmployeeService {  rpc Create(Employee) returns (EmployeeCreateResponse);
}

Here, Create is a method exposed by the EmployeeService service definition. Messages used in the Create service should also be defined as a part of the service definition. The Create service method is a unary service method because the client sends a single request object and receives a single response object in return from the server.

Let’s dig further into the types of service methods offered by gRPC:

• Unary: We have already discussed the unary service method in the previous example. This would have a one-way response for a single request.
• Server streaming: In these...

Exploring the RPC life cycle

In the previous section, you learned about four types of service definitions. Each type of service definition has its own life cycle. Let’s find out more about the life cycle of each service definition in this section:

• The life cycle of a unary RPC: A unary RPC is the simplest form of service method. Both the client and the server send a single object. Let’s find out how it works. A unary RPC is initiated by the client. The client calls a stub method, which notifies the server that the RPC has been invoked. A stub also provides the server client’s metadata, the method name, and the specified deadline, if applicable, with notification.

Metadata is data about the RPC in the form of key-value pairs, such as timeout and authentication details.

Next, in response, the server sends back its initial metadata. Whether the server sends initial metadata immediately or after receiving the client’s request message depends...

Handling errors and error status codes

Unlike REST, which makes use of the HTTP status codes, gRPC uses a Status model, which contains its error codes and optional error message (string).

If you remember, you have used the special class called Error to contain the error details because HTTP error codes contain limited information. Similarly, the gRPC error Status model is limited to code and an optional message (string). You don't have sufficient error details for the client to use to handle the error or retry. You can make use of the richer error model as described at https://cloud.google.com/apis/design/errors#error_model, which allows you to pass detailed error information back to the client. You can also find the error models in the next code block for quick reference:

package google.rpc;message Status {
  // actual error code is defined by `google.rpc.Code`.
  int32 code = 1;
  // A developer-facing human-readable error message
 &...

Summary

In this chapter, you explored Protobuf, IDL, and the serialization utility. You also explored gRPC fundamentals such as service definitions, messages, server interfaces, and methods. You compared gRPC with REST. I hope this has given you enough perspective to understand gRPC.

You also learned about the gRPC life cycles, servers, and clients with stubs. You covered Protobuf, gRPC architecture, and gRPC fundamentals, which will allow you to develop gRPC-based APIs and services.

You will make use of the fundamentals you learned in this chapter in the next chapter to implement the gRPC server and client.

Questions

1. What is RPC?
2. How is gRPC different in comparison to REST and which one should be used?
3. Which type of service method is useful when you want to view the latest tweets or do similar types of work?

Answers

1. RPC stands for Remote Procedure Call. A client can call an exposed procedure on a remote server, which is just like calling a local procedure, but it gets executed on a remote server. An RPC is best suited for inter-service communication in connected systems.
2. gRPC is based on the client-server architecture, whereas this is not true for REST. gRPC also supports full-duplex streaming communication in contrast to REST. gRPC performs better than REST as it uses static paths and a single source of the request payload.

A REST response error depends on HTTP status codes, whereas gRPC has formalized the set of errors to make it well aligned with APIs. gRPC has also been built to support and handle call cancellations, load balancing, and failovers. For more information, please refer to the REST versus gRPC subsection.

3. You should use the server-streaming RPC method because you want to receive the latest messages from the server, such as tweets.

Further reading

You can find out more at the following links:

• gRPC documentation: https://grpc.io/
• Practical gRPC: https://www.packtpub.com/in/web-development/practical-grpc