gRPC Introduction — Part 1
What is gRPC ?
gRPC is a modern open-source high-performance RPC framework that can run in any environment. It can efficiently connect services in and across data centres and connect devices, mobile applications, browsers to backend services.
This is a version of the statement put up by gRPC on their website. But seriously, what is gRPC ?
Before understanding the basics of gRPC, let’s understand how a client communicates with an API on a server.
A client can communicate with an API over HTTP using SOAP, RPC or REST. You can find tons of articles on these topics but what they really are some ways to represent the data sent over to the API on the server. You can call them protocols or architectural styles or whatever you want.
RPC vs REST
To understand gRPC, we need to understand the differences between RPC (or Remote Procedure Calls) and REST (or Representational State Transfer), or I should say, the use cases of RPC and REST.
Under REST APIs, everything is a resource, and a resource is a piece of information or data. What this means is that REST APIs follow the data-first approach. REST APIs are great for modelling a domain, making CRUD (Create, Read, Update, Delete) available for all of your data. REST is not “only CRUD”, but things are done through mainly CRUD-based operations. REST uses HTTP methods such as GET, POST, PUT, PATCH, DELETE, OPTIONS to provide semantic meaning for the intention of the action being taken. So basically, if you want to add a post to your Instagram account, REST is the way to go.
RPCs are nothing but calls to some functions like the calls you make in a Java program or a Python program or literally in any other programming language. RPCs are used to call a procedure on a server remotely. The basic function of a procedure is to act based on the information provided to it. The keyword here is “act”. RPCs follow action first approach. They are solely used to instruct the server to perform an action.
Now, you might think we can simulate actions in a REST API easily within its conventions if the actions are an afterthought. We can and we do because that is what we mean by data-first approach. But what if an action cannot be an afterthought?
Let’s assume you are looking for a cab ride on a mobile application and a cab driver accepted your booking request. This will POST the data to the “bookings” resource to insert a row in the “bookings” table of a database and change your status to “Booked” in some other resource as an action. Now the driver asked you the destination and cancelled your booking by specifying a reason. This is where it gets tricky. This now requires us to use DELETE method on the “bookings” resource and we also need to pass the reason for this action. But this reason is not specific to “bookings” resource. We are passing an arbitrary field to a resource under REST API. It feels like forcing an application into a paradigm that it doesn’t fit.
This is where RPCs come into action. Under action-first approach, we can call “deleteBooking” procedure along with the booking_id and the specified reason. This will delete the booking from the “bookings” and update the appropriate resource with the specified reason. As simple as that.
TL;DR
Using REST approach or RPC approach depends entirely on your use case and requirements. If your API is mostly using “actions”, then it should be RPC. If your API is mostly using “resources”, then it should be REST.
Now that we are familiar with the use cases of RPCs, we can jump over to gRPC and why Google created it, what was the need that JSON-RPCs and XML-RPCs could not satisfy.
