The GRPC API is a web API framework that is gaining momentum with the Architects as well as in developer community for modern Applications.
It provides an alternative, faster, and more efficient alternative to REST APIs. APIs are lifeblood of any Digital business.
But why Architects and engineers are increasingly looking at the GRPC API as their go-to solution for building APIs?
#1 What is GRPC and how does it work?
APIs are the lifeblood of any modern Digital business. They are the connective tissue that enables enterprise and external ecosystems to connect each other or the existence of the business.
Few things to note:
1. GRPC is a new kind of API that uses a different approach to communication than REST.
2. GRPC is based on the concept of Remote Procedure Calls (RPC). With RPC, a client can send a request to a server and the server can respond with results. This is different from REST, which uses a stateless, request-response model.
3. GRPC is more efficient than REST because it uses less bandwidth and fewer resources. It is also faster because it uses HTTP/2, which is a binary protocol that is more efficient than the text-based HTTP protocol used by REST.
GRPC is roughly 7 times faster than REST when receiving data & roughly 10 times faster than REST when sending data for this specific payload.
4. Some claim that GRPC is also more flexible than REST. Because it allows for different types of data to be exchanged, as binary data or protobufs. This makes it easier to add new features and functionality to an API without breaking existing code. Even though this claim is subjected to argument (over the flexibility of REST), it is worth noting down.
Overall, GRPC is a great choice over and above REST for building new APIs. It is more efficient and flexible, and it uses a more modern protocol.
REST is by itself is not a protocol, it is an Architecture pattern for exchange of data over HTTP protocol (the pattern is called Web API which we almost take or granted). GRPC is also a framework that makes use of HTTP/2 protocol.
#2 Adoption Trend of GRPC in Market
If you follow the market trends of adoption of GRPC in the recent years, you will spot few things.
Organizations would like to opt for GRPC for the high performance (latency, bandwidth) as explained above.
More importantly, GRPC API uses a type system which can help developers to catch errors early on in the development process. This can save a lot of time and money since it can prevent developers from having to debug their code later on.
Another thing I have discovered that the thought leaders in Salesforce and Google sees GRPC API designed to be extensible, which means that new features can be added easily without breaking existing code. This makes it easy for developers to keep their software up-to-date with changes.
Service mesh and gRPC have been fantastic for distributing service contracts so that teams can have a very well-understood, well-defined interface between each other over the network, whereas JSON and REST tend to be more fluid and leave a lot more open to interpretation
Plus, as a binary protocol over HTTP2, gRPC has an advantage over REST, a text protocol over HTTP1.
For Salesforce, HTTP2 has given us more flexibility in designing streaming services and push notification-type services where we wouldn’t be able to do that as easily with HTTP1.
Though the impact is hard to quantify, Salesforce believes that developer velocity has been improved as teams have evolved their services with maintaining backwards compatibility.
Another factor was the fact that gRPC is a polyglot framework. We’ve acquired companies, so we don’t have the luxury of a codebase written in a single programming language – So gRPC helps us by being available for all the languages we use.”Reference: https://www.cncf.io/case-studies/salesforce/
There are a number of large companies that have adopted GRPC as their go-to API for communication between services.
Some of these companies include Google, Netflix, and PayPal. Google is one of the primary backers of GRPC and has used it extensively within their own services. Netflix uses GRPC to communicate between their data center services. PayPal uses GRPC for communicating between their microservices.
Spotify, the music streaming service with over 200 million users, is singing GRPC for their backend APIs. Spotify has found that using GRPC has helped them reduce latency and improve performance. In addition, they’ve been able to improve the efficiency of their development process by using GRPC’s code generation features.
#3 To be or not to be: GRPC or Not?
Some Analysts predict that world would move to GRPC soon. We can debate whether edge services would adopt GRPC that fast, given the flexibility of REST and adoption of high-performance patterns like GraphQL and WebSocket.
When it comes to choosing a communication protocol for your microservices, gRPC is most often a great option.
However, there are a few challenges that you should be aware of before using gRPC in your next project.
Implementing gRPC can be complex
If you’re not familiar with the protocol, implementing gRPC can be quite complex. There is a lot of boilerplate code that you need to write in order to get started.
It can be hard to find resources and documentation
Since gRPC is still relatively new, it can be hard to find resources and documentation, especially reference implementation patterns and learning when you’re getting started.
The official documentation is very comprehensive, but it can be difficult to find tutorials and other helpful resources online.
It doesn’t work well with all types of existing back-end
GRPC is a great way to structure the API if we are working with a microservices back-end, but there is no unmixed blessings.
One of the biggest problem is that for large enterprises, there is a large legacy (monolith) footprint. If you are using a monolithic architecture, GRPC will not be a good fit.
Conclusion
“GRPC will be the modern API,” says Derek Collison. “It will co-exist with REST.”
GRPC is a high-performance, open source RPC framework that is designed to have better performance than HTTP REST and SOAP.
It will also provide rich interoperability between languages and platforms while requiring significantly less code. But with the ubiquity of REST, it will continue with REST.
REST at the edge with GRPC at the back-end is a win-win for all.