Introduction:

Recently I came across the discussion of choosing between gRPC or REST Service. So thought to summarize my research and opinion in a form of blog post, so that it will be helpful for one who are interested in this topic.

I saw there is some confusion among us as a Developer to choose one over another. So, let's get some dive into this topic. Hope this will give you some insights to give a fresh thought.

There is a lot to discuss about this topic. However, I have tried to keep this blog as concise as possible.

RPC vs REST:📢

Yes, it's not a spell mistake!
Before diving into the comparison, I think it is important to go through some fundamental difference between RPC and REST.

RPC:
I think RPC was there even before REST. REST came into picture in after evolving era of internet over HTTP protocol.
PC APIs allows developers to call remote functions in external servers as if they were local to their software.(action oriented in short)

Examples of RPC:
A client app “calling a remote API method” to perform “actions” like processing payment, sending messages, or retrieving data.

REST:
Where in “REpresentational State Transfer” is an architectural style that focuses on CRUD(Get/Post/Put/Delete) “specifically for the Resource” (e.g., books, users) (Resource oriented in short)

Example of REST:
A mobile app fetching product information by making an HTTP GET request to a RESTful API endpoint, enabling CRUD operations (Create, Read, Update, Delete) on resources like user profiles, posts, or photos.

Then Why REST replaced RPC?

REST didn’t replace RPC, but it grown as a popular alternative for building web services and APIs for various reasons. Both REST and RPC are different architectural styles with their own strengths and use cases.

gRPC:📢

Originally, the motivation for Google behind gRPC was to connect the large number of microservices running on same or different data centers.
As the payload size of gRPC vs REST is much optimized in size, it is somewhere 5 to 8 times faster than REST data transferred over network.
So they just picked the power of HTTP/2 and protobuff on top of RPC. ref

One of the key feature of gRPC is protobuf .proto file(nothing but just a contract for me between two communicator code components)
This file and protobuff compiler is so mature, then it generates a direct client implementation using protoccompiler. ref

gRPC weaknesses:

Every technology comes with their own power and downside; hence it is important to focus on their use and Use cases.

1. Limited browser support: since gRPC uses HTTP/2 protocol, not all modern browsers support very well.
2. Not human-readable format of message: I read some articles heilighting this as weakness. But in my openion, why should we care about this ? as far as sender and reciver understands it very well, I dont see any problem with this.
3. Limited number of error codes: gRPC has less number of error codes if we compare with REST. ref

Challenge and Considerations When Using gRPC in Microservices

I think, it makes sense to use gRPC in microservice(internal layer) of architecture but carefully!
Why am I emphasizing on ‘carefully’? First let's see the problem referring below scenario,

Client (referring to a service caller) calls for an action to gRPC_service_1.
gRPC_service_1 service internally “maybe”(we don’t know as a caller) calling gRPC_service_2, and gRPC_service_2 might call other services internally.

But there is one challenge with this design!
What if, there is a strong business workflow involved/associated in this hole cycle and somehow gRPC_service_3 fails? As a result, it will cause some inconsistency within services, and gRPC_service_1 does not know which of the components failed in the chain (rather I would say failure in business workflow).

My Thoughts of using gRPC effectively in web API development✍

I am proposing above high-level architecture of where I think gRPC makes more sense, and why.
I considered below points while proposing this high-level architecture.

1. Most of the browsers doesn’t support HTTP/2 hence gRPC very well.
2. Architecture should be workable with both the scenario: a) if having strong business workflow, and hence better to decouple the modules b) if do not have strong business workflow and flow ok with failure in chain.
3. Architecture should be flexible enough for shifting to gRPC seamlessly from REST, without any change in internal modules.
4. Should be scalable over time.

Let's Architect,

Okay, some developers may be having some diabetes over these components. Be flexible enough to change any of the above modules based on your needs or Use case.

Web Interface Layer:
🔹Gateway Service:
If you are using this layer as your REST gateway service and your internal services are hidden from the external user, it's a big win to tackle the browser compatibility problem for WebUI clients.
Most of the Gateway services supports to configure Upstream as REST protocol and Downstream as gRPC and vice versa. By this way you do not need to worry about switching from gRPC to REST for your external clients without changing your internal structure. Isn’t it Great!!!

🔹BFF Service:
This is one of another Usecase where you make your view composition by using underlying core services.
Aggregating your logic using gRPC and sending back data to your clients as per your choice or protocol (e.g. REST/WebSocket) makes your decision flexible enough.

🔹Aggregator Service:
This service is very much similar to the BFF, but the core difference is, BFF is built with frontend needs in mind, and responsibility of Aggregator service is to summarize the data by contacting two or more services behind the scenes.

“Business Workflow?” block:
I am not sure; what term this block we should call to. You can suggest a better name, but you get the point!
This block is little bit tricky while implementation and taking decisions.

If there is no business workflow involved, then I think it's okay to have direct call to another service to retrieve data. You can use any resiliency framework internally though to deal with temporary service down delay.

But if, there is business workflow involved then you can consider messaging queue to make your flows/system decoupled and flexible enough in nature. Using messaging queue brings up its own power and strength though.

Okay, then shall I ‘move’ from REST to gRPC now?

The answer I would suggest: If you are starting a project/service newly (newly, I meant the reference is not exists yet anywhere), you can give a thought to have service as gRPC.
But there is no concrete reason that you must have it until and unless there is any need.

References for more detail📗

1. RPC vs REST — Difference Between API Architectures — AWS (amazon.com)

2. Performance best practices with gRPC | Microsoft Learn

3. GRPC Core: Status codes and their use in gRPC