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.
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…
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.
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.
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.
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.