Learn the basics of gRPC and see why it has grown in popularity, when it should be used and how. Ballerina, a network-aware programming language, is used.
Introduction
In this article, we will take a look at what gRPC is, when we are supposed to use it, and how exactly we can do so. We will also compare and contrast technologies used in similar domains. For code examples, we will be using Ballerina (referred to as Ballerinalang in the article), which is a programming language optimized for network-aware applications.
REST vs. RPC
The main requirement in question is the communication between programs in a network. In a standalone application, our communication is between in-process objects, where we do direct function/method calls. In this way, there is no requirement for communicating with an external program to get any required functionality. But as time moved on, we have started designing our applications to work in a more distributed manner. We would expose part of our business logic as an external service to be used by multiple consumers who are interested in doing so. So now, we need a communication mechanism when accessing these networked-endpoints.
A popular approach for accessing these remote services is using REST (Representational State Transfer). But when we talk about REST services, we tend to use this term loosely, where many of the service implementations do not fully adhere to the definition of a RESTful service. An important constraint of being a REST service is where our navigation through resources should be driven by hypermedia along with the knowledge of specific resource media types.
Figure 1: Persons REST API
Figure 1 shows an example of a REST API, which is used to expose information related to “persons”. The API starts with a single entry point, and it navigates through its resources to get the required information as needed.
But generally, when we try to design REST APIs, we use direct knowledge of resource locations in the APIs when accessing them. A standard used to define these HTTP resources is OpenAPI. It defines the resource paths and the methods when defining operations of an API.
In a REST API, the resources represent some type of information. So it’s more aligned with representing data entities. This data is accessed and manipulated with CRUD (Create, Retrieve, Update, Delete) operations. Thus, it’s not directly possible to express an action using a resource, but rather, we are only able to emulate them. For example, sending an SMS can be represented by an HTTP POST action to the resource “/sms”. So this is can be seen as adding a new resource to the “/sms” resource collection, which gets mapped internally to the action of sending an SMS to a specific location. So even though it’s possible to model the actions also in the same way, it is not the most natural thing to do. This is where the RPC (Remote Procedure Call) mechanism comes into play.
Figure 2: Admin RPC Service
Figure 2 shows an RPC service that contains several actions. You may have noticed that we have modeled our earlier data entity operations as actions as well, with addPerson() and getPerson(). By following such a specific convention, we can also represent our CRUD operations in an RPC approach.
Many RPC technologies are ranging from XML-RPC to SOAP to gRPC. These technologies have evolved into novel approaches for improving functionality, user-friendliness, and performance. gRPC has become one of the most popular technologies currently used for RPC. It is a binary protocol based on Google’s Protocol Buffers and works on top of the HTTP/2 transport. It promises high performance and features such as schema evolution and bidirectional streaming. If you find yourself modeling your API operations as actions most of the time, then it is a good sign that it should be modeled as an RPC solution. gRPC is supported widely by almost all of the mainstream programming languages, which makes it a popular choice for implementing APIs and their clients. Also, due to the underlying usage of HTTP/2, it follows an efficient network communication approach by multiplexing multiple streams through a single TCP connection. This allows the application to avoid the overhead when creating multiple network connections for separate communication channels. The programming model also supports the use of blocking and non-blocking communication, along with streaming features.
Let’s take a closer look at how gRPC works, and the tools and techniques that are required to implement it. The first aspect is the service definition using Protocol Buffers.
#microservices #rest #ballerina #grpc #developer
