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