gRPC vs REST

Every developer must have heard about REST in his/her life. REST stands for REpresentational State Transfer. It has been the most renowned software architectural style for API's in the software industry, until a few years back when GraphQL entered the market in 2011. But still REST has held it's position among developers since it's introduction in 2000. Both REST and GraphQL have their advantages and disadvantages. REST can be used for caching, which is still in the development phase for GraphQL. GraphQL removes the need to call different API's to get the data needed from the server because it uses a query based design and thus all the data can be fetched in just one query.

Developers have been arguing on this topic for quite some time. But it hasn't yet being decide that whether REST or GraphQL, which one of the two is the best for the future Developers.

REST will soon be Rest In Peace - By I don't remember who

But today we are not here to discuss which architectural style is best for API designing, which is been discussed already quite a lot and having another discussion on it would be a waste of time for both of us, but we are here to decide that which architectural style is best for communication between microservices.

The Main Picture

The picture changes a bit when we start to talk about microservices communication. GraphQL has moved out of the picture and now in it's place we have one of the oldest in the line of API designing techniques, RPC, short for Remote Procedure Calls.

RPC or Remote Procedure Calls is a way of making calls to functions which are on another remote machine. In REST we make API's based on different resources, like users, employees, orders, whereas in RPC we make API's based on different functions, like createUser, readUser, createOrder, readOrders. RPC was one of the earliest Architectural Patters for communication between client and server. gRPC is a RPC framework developed and maintained by Google.

You might be thinking how can I compare a framework with a Architectural pattern ??? Well gRPC is more than just a framework, it also lays down some rules on how the client and the server communicate because after all it is a framework that is built for RPC communication. So, I'll be using gRPC and RPC interchangeably throughout this article.

Comparing our Competitors

• gRPC is based on HTTP 2 and uses Protocol Buffers as the message format. It serializes data to communicate via binary. Protobuf is language and platform agnostic as it supports more than 10 languages. Whereas REST can be used with any valid HTTP version and can return data in any format(JSON/XML).
• RPC have a specific typed schema for their message format because it uses Protobuf but in case of REST there is no need for a specific message schema.
• The message transmission is faster in case of RPC because it transfers data in a serialized compressed format and also because of which it is less human readable than JSON. It is also fast because it uses HTTP 2 under the hood.
• Communication in gRPC can be unary(request/response), server streaming, client streaming or bi-directional streaming using the streams provided by HTTP 2 to it but in case of REST, it is just limited to simple unary(request/response) communication. And not having streams is a big drawback according to me. (Note: Remember WebSocket servers are not RESTful)
• REST uses a lot of the features of the underlying HTTP layer like the HTTP verbs, caching, etc. On the other hand gRPC uses non of these features. The only HTTP method used by gRPC is POST and it does add some of it's own headers to the request and response on top of the HTTP headers which it requires.
• REST uses the concept of GET and POST method calls along with body's, queries, headers, etc of the HTTP layer to communicate with the server but in the case of gRPC it is just function calls with arguments or parameters send along.
• There hasn't been any single specification for REST, which has created a lot of confusion over the years but with the onset of gRPC, Google has set some ground rules for communication when using gRPC.
• gRPC has this very good feature embedded in it know as Deadline propagation, which is missing in the REST architecture. What Deadline propagation does is that it automatically adjusts the timeout values after every hope it takes, either through a service or a proxy, based on the timeout value set by the client. Obviously we can't hold REST responsible for this because after all it is just an API design style.
• gRPC is asynchronous by nature and REST tends to be synchronous by default.
• You can communicate with a REST server using your browser but the support for gRPC is still not provided by browsers.

REST Request Example

POST /api/signin HTTP/1.1
HOST: my-server
Content-Type:application/json
Accept:application/json
authorization = Bearer y235.wef315yfh138vh31hv93hv8h3v

{
  "credentials": {
    "name": "administrator",
    "password": "passw0rd",
    "site": {
      "contentUrl": ""
    }
  }
}

gRPC Request Example

HEADERS (flags = END_HEADERS)
:method = POST
:scheme = http
:path = /google.PublisherService/CreateTopic
:authority = pubsub.googleapis.com
grpc-timeout = 1S
content-type = application/grpc+proto
grpc-encoding = gzip
authorization = Bearer y235.wef315yfh138vh31hv93hv8h3v

You can observe the different content-type accepted by the requests. REST has the application/json response type whereas gRPC has application/grpc+proto response type. The path variable in the gRPC request has the name of the microservice along with the name of the function which it is calling.

google.PublisherService -> Service Name

CreateTopic -> Function Name

The Main Question

gRPC features like Deadline propagation makes it resilient, being asynchronous in nature helps it to handle multiple requests, having the capability to communicate using streams gives it the capability to send data back to the client one at a time or as and when it fetches data from the database instead of all at once and at last being faster than REST to send and receive data makes it the better choice for inter-service communication. Since gRPC has a strongly typed schema for message formats, it makes it easier for different teams to generate the message format and even the code for the all the functions of a service which are defined in the proto file using the protoc compiler provided by Google. This is also an advantage of gRPC as we can generate the code for all the functions of a service by just using the proto file.

gRPC might loose the war to REST when it comes to designing public API's but in this case it is the winner because when it comes to communicating between services, we don't need data to be transferred in as human-readable form as possible, we need it to be fast and the data size to be less.