gRPC vs REST – A complete guide
With the fast-paced technology evolution, software developers are actively finding the most successful and competent way to do things. While it is always all about making something more and more efficient, it’s often only a matter of milliseconds when it comes to the software world.
In this blog, we shall discuss one of the problems where one millisecond really counts and how we need to move our web services from REST (Representational State Transfer) to gRPC (Remote Procedure Calls). In fact, this blog is intended for technical experts who know all the web services profoundly.
Is gRPC faster than REST?
Definitely Yes! gRPC is faster than REST. However, we need to spend more time (approx 30 min extra) executing any fundamental gRPC Service, as opposed to the output of the same basic REST API. This is mainly because REST is already established standard and the most relevant systems such as ASP.NET, Core MVC have built-in support to quickly spin-up such services.
gRPC too has made certain advances, such as we don’t need to physically run the “protoc” compiler and it is now already in the Visual Studio chain. All we must do is to utilize the “Protobuf” ItemGroup in our csproj document. Likewise, in ASP.NET Core 3.0 we can anticipate the closer mix of gRPC soon.
In one of the recent studies, gPRC is approximately 7 times faster than REST when the data is received and about 10 times faster than REST when the data is transmitted for the specific payload. This is mainly because the protocol buffers are packed tightly, and HTTP/2 is used by gRPC.
(Disclaimer- Data is for a Dummy Sample Service)
Is gRPC restful?
The fact is that gRPC is another interpretation of an old methodology known as RPC or Remote Procedure Call. RPC is a technique to execute a strategy on a remote server. It’s like running a program on a companion’s PC miles from your workstation.
One of the biggest differences between REST and gRPC is the payload format. Usually, JSON format is used in REST messages. In theory, you can send anything as a response in JSON. But in practice, the entire REST ecosystem including tooling, best practices, and tutorials is focused on JSON. Hence, it’s fair to assume that REST APIs accept and return JSON with very few exceptions.
gRPC, on the other hand, accepts and returns Protobuf messages. Protobuf is a very efficient and packed format from the performance point of view. JSON on the other hand is a textual format, you can compress JSON but the chances are you may lose the benefit of textual format.
|Code Generation||Built-in protoc||Third-party Tools|
|Streaming||Bidirectional||Client to Server request|
When to use gRPC?
Instead of a text-based messaging protocol, we can leverage a binary protocol that is optimized for inter-service communication. The Cloud Native Computing Foundation’s gRPC is an ideal choice for communication between services, using protocol buffers as a bilateral data exchange format. gRPC uses HTTP/2 allowing multiple messages to be linked in one connection. It is useful when you stream other data using gRPC ‘s streaming feature which has the ability to send multiple messages as part of a request. gRPC gives you a few more ways of streaming such as Server side, Client-side, and Bidirectional.
When we construct multiple microservices using different technologies and different languages, inter-service communication is always required for consistently defining service interfaces and underlying message interchange formats. gRPC provides a simple and secure way to define contracts for operation with protocol buffers. Therefore, gRPC can be the most viable alternative for building communication between internal microservices.
How are microservices and gRPC related?
Almost all accept that the common concept of microservices is about organizing the entire logic of a single software application in a smaller service collection, and each small service will perform a monolithic work. Each constituent service is much smaller in size and complex than the single application itself. These services are treated as independent units of the application and are implemented and deployed autonomously. Another important aspect is that each microservice will be fully responsible for its own data and very likely to have its own database or can have a shared Database with a separated Schema. Nonetheless, it all depends upon the requirement and the resource available.
gRPC plays an important role in this microservice architecture. For example, let us say an online retail website has microservices as product-search service, inventory-service, order-service, and payment-service. The consumer is interacting directly with the REST API to the Product-service and the Product-service is communicating through gRPC with other (micro) services.
In the above architecture, we benefit from gRPC’s quick response and request time. At the same time external-facing communication can be restored on REST as most external clients know how to communicate with HTTP RESTful service.
Why migrate from REST to gRPC?
The key benefit of designing services with gRPC is:
- Decoding JSON or related text-based messages is not required within the application or service code (using libraries such as Jackson).
- The wire is a binary format (protobuf) which is unmarshalled into an object.
- gRPC Interface Definition Language (IDL) provides powerful support to design service interfaces and address multiple microservices & maintains interoperability.
It is important to consider the ability to migrate all the microservices from REST to gRPC. For instance, if the product service mentioned above was to be transferred from REST to gRPC, a lot of rework was required for the consumer. For such scenarios, there can be possibly two solutions:
- Solution 1: Create a gRPC app and use the gRPC Gateway. It is a plug-in of the Google Protocol buffer compiler client. This server reads the definitions of the protocol application and generates an inverse proxy server which will translate the RESTful HTTP API to the gRPC.
- Solution 2: Cast a gRPC call inside the REST call. So, from outside it will be a REST call and from inside it will be gRPC Stub classes. The gRPC stub classes are generated when you run the protoc compiler and it finds a service declaration in your proto file. The stub classes are the API your client uses to make RPC calls on the service endpoint.
Finally, we can build our new microservices using gRPC based on the number of microservices, performance, and maintainability requirements. And then migrate all of our existing microservices to gRPC, where applicable. This provides:
- Strongly typed service and request/response definitions that are written once and can generate code in multiple languages
- Better performance with HTTP/2 when reusing connections
- One less thing to maintain in terms of building client libraries
- Support for high data load streaming calls
Neeraj Chaudhary | Senior Software Engineer
Neeraj Choudhary is a senior software engineer at GS Lab and has over 6 years of experience in application development, enhancement, maintenance, and service delivery. Currently, he is working on implementing gRPC calls in his projects. He has good exposure to product development across legal, banking, and VOIP domain products.