Why gRPC might not be right for you ?

1. What is gRPC ?
2. gRPC vs Http
3. gRPC Web
4. Why gRPC is not a replacement for REST API ?
5. Conclusion

What is gRPC ?

In simple terms gRPC is a RPC(Remote procedure call) framework developed by google. No, "g" in gRPC is not google. But google open sourced the project. Since then gRPC is trending. It uses protobuf (Protocol buffers) to define the functionality of a service. It acts as documentation for your service and using the same protobuf other services can call functions in your service. It is fast, reliable and trending. It supports streaming and it supports multiple languages. Then why it might not be right for you ? I have seen blog posts promoting gRPC as a alternative for REST. But from my experience gRPC Never meant to replace RESTful APIs. Why? Let's see.

gRPC vs REST

First of all lets see what are the major difference between both gRPC and REST, but from a pure development experience perspective then functional perspective. REST service can be developed with most of the programming languages, and it's same for gRPC. Even though gRPC libraries are not available for every programming languages. There are libraries available for mostly used development stacks. There is no in built documentations available for REST API, but we can use external tools like swagger which support OpenAPI Specificationto build API Documentation. In gRPC proto files has to be created in advance to generate the platform specific library files. All of these proto files can be used as a documentation of a service. Though writing and handling proto files is tedious job, it pays off when it can be used as a valid contract between services. There is server reflection package to expose available methods and payloads inside a grpc server. It comes in handy during debugging and development process.

REST is basically collection of requests with different http methods but it always follow request and response paradigm. It is simple to understand and conventional.

On the other side gRPC lets you to create 4 types of methods:

• Unary RPC It is more like a traditional request and response structure.
• Server streaming Here client can send a request and recieve a stream of message from the server.
• Client streaming Client can send a stream of data into the server and server returns a message back when stream ends.
• Bi directional streaming Read-write stream. Two different streams therefore client and server can read and write in any order. Order of messages in stream is preserved.

I am not explaining it in much detail. You can go to link and check out yourself. Image shows the basic working of gRPC and how protos is exchanged between services.

Maintaining proto files is a tedious task because in microservice architecture we use multiple programmming languages for servers and clients. So we have to genereate server-side and client-side code from the protobuf file using protocol buffer compiler. It get's difficult to handle manually when you have couple of services with different languages. Packaging of client-side/server-side code is mandatory using some kind of automation. So whenever a new version of proto file is updated in repository, client-side code can be generated using the plugin for multiple languages and others can easily update to it. This requires bit more resource and planning compared to REST.

gRPC Web

Yes. It is possible to directly access a gRPC server from web. But it comes with some of caveats. Right now gRPC does not support direct connection to any gRPC implementation. We have to use proxy like Envoy to connect to our service. Native support for gRPC web is on the development road map. But till then if we want to connect our web app to a gRPC service we don't have much options. And with different moving parts the complexity and possible points of failure goes up. This is without considering the resources and skill required to configure a envoy proxy and maintaining the same. Most of the small to medium projects might not require this level of complexity. Also all projects need not to be implemented in microservices architecture and building and maintaining a gRPC service for simple web app is bit of an over kill.

Why gRPC is not a replacement for REST API ?

I personally don't think gRPC is supposed to replace REST API. It does not support web right out of the box. There is no point using it while you are working on a single service application. It is useful if you have any scenario in the system to stream any data in between like logs and events. But again that does not make gRPC and alternate solution for REST. gRPC will be very efficient if you want to build a cli or a package with communication to the server, gRPC is really apt for it. One example would be how google's firebase package use RPC for their implementation. One another best scenario would be log/event/stream processing. Above all of it, resources needed to implement gRPC is higher than REST. So the application of REST and gRPC seems different to me. Even though it can be used interchangeably.

Conclusion

Don't get me wrong gRPC is a great framework. It's fun to play around with. But unless you are not utilizing features like Bi directional streaming and other streaming methods, the overhead has to be justified. Also the use case is really important when it comes to the adoption of gRPC. Using something like gRPC to just build a simple request-response microservice would be pointless.