This article has unexpectedly become the most popular post on this blog, so I thought I would respond to different people in an aggregate comment:

Responding to Clark:

-[Referring to multi-language support] Is this different from REST? You can serve JSON from a Java-implemented endpoint to a python-implemented client via HTTP.

A feature of gRPC is that it works across programming languages. You define services, gRPC auto-genreates language-specific files, and you can communicate with clients and servers that use different programming languages. This was not meant to imply that you cannot achieve the same thing with REST

The HTTProtocol is language agnostic...You can even implement a RESTful using gRPC (please don't) -- meaning gRPC vs REST is misleading.

That is a completely legitimate point

Comparing gRPC as a communication protocol to HTTP makes more sense than comparing it to REST

gRPC is built on top of HTTP/2, so I don't know how useful it would be to compare gRPC to HTTP

The real diff seems to be between protobuf and json perf over the wire. And, how close to the bare wire that data is transferred.

Right

Responding to others

Ok, :) what could be real reasons to use gRPC instead of REST?

First of all - architectural reason.

I still think speed/efficiency is a completely valid reason to use gRPC instead of REST

Having used both fairly extensively with Go and Node.js I'd say my preference depends on what I'm doing. Mostly these days I use REST for communication "outside" of what I control and gRPC for internal systems as much as possible.

From what I've seen this is the most common paradigm emerging.

Thanks for that, Damion. Also, thanks for the info Benjamin Jordan, and everyone else who has commented.

I would definitely be interested in hearing if anyone had experience with grpc-web. That is the next natural place the conversation would go.