Is gRPC a good idea?

So I seem to have started this discussion a few times recently about GRPC and got quite a wide range of opinions so thought I’d collect them here.

Is GRPC something that helps alleviate some of the potential potential pitfalls in RPC?
Or, is RPC a bad idea always and this implementation does nothing to help overcome the fundamental flaws.



Steve Vinoski summed it up so well almost 10 years ago that I haven’t felt the need to discuss it.

IEEE Internet Computing: July/August 2008, Convenience Over Correctness (pdf)

The RPC topic in general came up recently here.

For historical perspective - the initial paper:
Birrell, A.D and Nelson, B. J., “Implementing Remote Procedure Calls” Feb. 1984 (pdf)

and a major critique:
Tanenbaum, A.S. and van Renesse, R., “A Critique of the Remote Procedure Call Paradigm” - 1988 (pdf)

… and one blogger’s contemporary musings (twitter) about the two.


I’ll have to check these out, thanks!

1 Like

For a really good write up and bibliography of the work against RPC :

For a recent take by Chris


My point of view : HTTP/2 itself is a mistake, it should not have been called HTTP, but be a separate thing. But now that it is named like that vOv. It is already breaking the one url = one ressource which is the definition of what HTTP means…

1 Like

I agree with this but not that HTTP/2 was a mistake. I think it was called HTTP/2 to some degree to push the agenda of using TLS for all communication.

also no idea what vOv means

1 Like

gRPC is now under Cloud Native Computing Foundation .

1 Like

Having explored it a bit more I have found this talk which is quite good on best practises for GRPC.

In summary I think yes GRPC is a good idea. The first thing the presentation above suggests is that an API should be idempotent. This makes GRPC a very convenient way to describe API’s and if requests can be retried safely then a lot of the best ideas from message passing can be applicable to a system using it. The response from a call being best considered as an ack.


What is the quality of Elixir’s GRPC libraries? Is anyone using GRPC / Elixir in production today?

1 Like

rough, proceed carefully

I was initially skeptical of GRPC, because it has RPC in the name, which I consider a failed idea. However, despite the name, I feel like GRPC isn’t really RPC in the classical sense of a method transparently making a network request. I personally prefer communication over a message queue, but GRPC seems to provide many of the same benefits. So, I think GRPC is a good idea.

1 Like

There are even libraries that you can call GRPC directly from JS

I think RPC in general is a ‘good idea’ insofar that it is another possible tool amongst multiple possible solutions. It definitely is not a silver bullet. Many of the things that people would use RPC for in other contexts might be solved in Elixir by other means by using its process-oriented architecture.

RPC’s main weakness is that it is invisible for the caller that a lot of work that depends on external, unpredictable, conditions is happening in the background, which means that you need to take care to keep your system remain fault-tolerant.

gRPC specifically seems interesting, but if you for instance already are sharing work in other response/request formats using e.g. RabbitMQ, you could leverage that instead of adding yet another moving piece of complexity to your application stack.


The biggest sell here is for service-to-service communication. gRPC solves a lot of problems compared to using REST. It also enables some interesting architectures with its server-streaming, client-streaming, and duplex streaming but I think that’s secondary to the replacement of REST (again, only for backend-to-backend). Of course, there will always be problems better solved using RabbitMQ or Kafka.

gRPC would really help with the introduction of Phoenix apps as the client-facing APIs vs Rails or NodeJS apps as a part of micro-service clusters.


There is aslo rsocket