← Back to context

Comment by paulddraper

3 days ago

The critical problem with gRPC is that it uses protocol buffers.

Which are...terrible.

Example: structured schema, but no way to require fields.

Well the competition is REST which doesn’t have a schema or required fields, so not much of a problem.

  • > Well the competition is REST which doesn’t have a schema or required fields, so not much of a problem.

    A vague architecture style is not competition to a concrete framework. At best, you're claiming that the competition to gRPC is rolling your own ad-hoc RPC implementation.

    What I expect to happen now is an epiphany. Why do most developers look at tools like gRPC and still decide it's a far better option to roll their own HTTP-based RPC interface? I mean, it's a rational choice for most. Think about that for a moment.

With Protobuf this is a conscious decision to avoid back-compat issues. I'm not sure if I like it.

  • That's exactly how these systems fail in the marketplace. You make one decision that's good for, say, 50% of cases but disqualifying for 50% of cases and you lose 50% of the market.

    Make 5 decisions like that and you lost 31/32 of the market.

Some people complain about that, but I have yet to see anyone demonstrate that this is an actual problem. Show me the scenario where this is a show stopper.

You have all the permutations that sail under the name "REST" to some degree, where there seems to be no rules and everyone does something different. And then you have an RPC mechanism that is about two orders of magnitude tigher and people complain about not having required fields? How? Why? What are they on about?

I mean, if you write validation code for every type, by hand, you will probably still have to do less overall work than for REST'ish monstrosities. But since you have a lot more regularity, you can actually generate this code. Or use reflection.

How much time do people really spend on their interface types? After the initial design I rarely touch them. They're like less than a percent of the overall work.