gRPC is a promising communication technique that has already gained a considerable footprint in the API area. It’s been around since 2012 and there are many leading tech companies adopting gRPC, such as Google, Netflix, & IBM. It’s becoming more popular, and it’s good to know what it is and how to decide when to use it. Nowadays, you could see gRPC as an alternative to REST and GraphQL from a request/response perspective and an alternative to WebSockets from a streaming perspective.
What is GRPC
gRPC is a high performance, open source remote procedure call (RPC) framework. A remote procedure call (RPC) is when a program can execute a procedure on another machine as if it were a normal (local) method. gRPC can be used with different data formats, but usually and by default Protocol Buffers are used. This is a language-independent, binary file format for serializing data. It also has backward and forward compatibility support.
Advantages of protocol buffers:
- Compact in data format.
- Parsing performance.
- Support in many programming languages.
- Optimal functionality through generated code.
gRPC use cases
The main reason for using gRPC is performance. For example, gRPC is 7 times faster than REST when receiving data & 10 times faster than REST when sending data for a payload(Source). This is mainly due to the tight packing of Protocol Buffers and the usage of HTTP/2.
Besides the main advantage, gRPC could be considered in the following use cases for projects:
- For mobile applications and IoT Devices since they do not need a web browser and can benefit from small, efficient messages (Protocol Buffers). This results in less data traffic and also preserving a tablet/mobile’s CPU usage (which saves on battery).
- For communication between internal (micro) services, especially in multi-language systems. Since gRPC provides the possibility to define a strong API contract (Proto file), this file can be used to generate code in multiple supported languages (Java, C#, Go etc.). In this way, the generated code can be used for services to call each other while being in a different language.
- For inter process communication, it’s becoming more and more the standard. Examples are Unix sockets and named pipes that can be used with gRPC to communicate between applications on the same machine.
Alternatives to gRPC
There could also be alternatives like:
- REST API is generally the most simple and popular choice, since it has become quite the industry standard. It’s most suited for web (client)- server communication and public API’s.
- GraphQL is relevant if you want a flexible API where different clients make custom requests. In this way, it’s possible from the client side to get the specific data they need.
- WebSockets is a better fit when the system is sending the same message to multiple users at once. Various WebSocket libraries implement broadcasting over WebSockets (usually via pub/sub mechanism for messaging). Whereas, gRPC does not natively support broadcasting.
- For web related streaming, WebSockets should be the preferred way, since you probably want to support all browsers. In gRPC there is a workaround using grpc-web. But this introduces extra complexity within the architecture by adding a proxy.
Keep in mind that in a real life project, there are always requirements that do not fully match a given communication protocol. If that happens, try a small PoC with one or two communication protocols and check what fits best. It’s also wise to note that decisions could be made based on business constraints, e.g: What skills do we have with our current team? Or what is our budget for this project?
gRPC limitations
When considering gRPC, make sure you are aware of the following limitations.
- Lack of maturity, which could lead to a steep learning curve.
- If you compare gRPC 5.6k s/o questions to REST 90k s/o question or GraphQL 19.4k s/o questions. This could mean that gRPC could lack information about issues, proper documentation, best practices, workarounds, and success stories. But this is likely to change soon as gRPC is getting adopted more and more.
- Limited Browser Support
- No modern browser provides the control needed over web requests to support a gRPC client. Therefore, a proxy layer grpc-web is required to perform conversion between HTTP/1.1 and HTTP/2 which also introduces extra complexity in the architecture.
- Extra Maintenance overhead
- If gRPC is a new communication protocol for your tech stack, it could bring in some additional complexity. Because maintaining a gRPC project could require new tools and knowledge which will add additional overhead to the maintainers.
- No caching by default
- Caching requests and responses are by default not supported in gRPC. A workaround could be a custom middleware layer, but this will introduce extra complexity in the architecture.
Conclusion
We’ve explored the use cases for gRPC and possible alternatives (REST, WebSockets and GraphQL). We’ve also gone through some major benefits of using gRPC, as well as its limitations. Hopefully, this article has helped you to understand what gRPC is, the alternatives besides gRPC and how you should make a decision on either.
