> they get virtually no benefit from using grpc because they aren't performance-bound. They are simplicity-bound.

If you're talking latency, to this day gRPC in dynamic languages is still slower than most fast json implementations in _latency_.

It is simply not correct to talk about "performance" this way.

If you care about CPU allocation and not burning 70% of your CPU on JSON parsing, then sure. Most companies don't care about that, and I/O is 3 orders of magnitude a bigger problem than in-process parsing for those problems.

I think this is another reason why solo developers don't benefit from grpc the way a billion dollar company does: solo developers often aren't using languages that are optimized with grpc (eg they're using python, node, Ruby, sometimes go; they aren't using c++, Java, etc)

Obviously these aren't hard and fast rules, but Google can't just spin up 10x more data centers to run their resource intensive stuff in something other than c++ or Java. They need the efficiency in a way solo developers or small teams usually don't.

Yep! That's the nuanced argument I'd look for, as opposed to 'gRPC bad, they added it because they're from google!'

Simplicity wise my favorite scenario is where if I'm using Python I can pip install an interface (or maven, or NPM, etc. etc) which is the versioned, supported interface for a component. REST + Swagger can help a lot there. So can gRPC. But I can also get how your favorite scenario might be to explore a REST API and build your own client.