I’m not very convinced by that article. There are reasons besides amateurism to design an IDL with a restrictive type system. When you want bindings in many different languages, you need to be thinking about their least common denominator. A feature like user defined generic types would be challenging to support across all languages in a consistent way.
Eh this is just a horrible article, and shouldn’t be re-circulated
It’s certainly valid to say that protobufs are not appropriate for a use case, or even not appropriate outside Google except in limited circumstances (e.g. if you don’t have a monorepo)
Granted, on paper it’s a cool feature. But I’ve never once seen an application that will actually preserve that property. With the one exception of routing software, nothing wants to inspect only some bits of a message and then forward it on unchanged. The vast majority of programs that operate on protobuffers will decode one, transform it into another, and send it somewhere else.
But he’s missing the whole point, and hasn’t worked on anything nontrivial that uses protobufs
I would go look at what this person has actually built, and then go look at what people have built with protobufs. (I didn’t actually go look, but I can already tell by the way this article is written)
We use JSON-RPC ( https://www.jsonrpc.org/specification ) - which is really just a loose standard around formatting an RPC call over the wire as JSON. We don’t have any regrets going with that over gRPC (which was the only real other alternative when we picked it). I like that it covers virtually all use cases you’d need, is easy to hand-write when necessary, and (with a bit of TypeScript or JSDoc) can give you most of the benefits that you get immediately without moving into the realm of diminishing returns.
FlatBuffers seem popular as a replacement. I’ve not used them but some teams 8 worked with moved to them and found that they were fast and simple to use.
I’ve meant to write a rebuttal to this for years, but I think it’s a question of framing.
If you frame it about as describing a language (ie: a grammar for serialising a particular type) then it makes a little more sense. The whole issue is that he’s trying to cram an ADT style worldview (which is relatively tightly coupled, but that’s okay because it’s in-process) into a distributed world, where versioning is a problem.
TBH the biggest problem with gRPC is A) protobufs are bad and B) most people conflate gRPC and protobuf without realizing you can replace the encoding with a better one.
I honestly don’t have a problem with gRPC on its own, provided it’s used with a good encoding.
I’m on the other end of this (been using gRPC and loving it – mainly the end-to-end type safety), what made it suck in your experience, and what alternatives did you look at that might be better?
I find it darkly humorous that one of the downsides of using gRPC-web is that it doesn’t work well with the Chrome devtools.
Like, really? Out of all the monopolistic shit Google has pulled with Chrome, not including gRPC tooling (even if only for their own internal users) in devtools was a red line in the sand for them? (If this company felt it was a problem, Google engineers presumably did as well.)
gRPC is a standard way of working, so if. you adopted a standard way of working, and it worked, that’s awesome. But that isn’t an inherent advantage of gRPC. It’s the advantage of saying “We’re going to work like this” and meaning it.
You could accomplish the same with Avro and Kafka, or JSON Schema and HTTP, so long as you all work in accordance with the agreed standard way of working.
None of this addresses any of the fundamental design flaws in protobufs: https://reasonablypolymorphic.com/blog/protos-are-wrong/
We’ve suffered thru 5 years of protobuf at my work and not only would I ditch it if I could, I’d strongly advise anyone considering it to stay away.
I’m not very convinced by that article. There are reasons besides amateurism to design an IDL with a restrictive type system. When you want bindings in many different languages, you need to be thinking about their least common denominator. A feature like user defined generic types would be challenging to support across all languages in a consistent way.
Eh this is just a horrible article, and shouldn’t be re-circulated
It’s certainly valid to say that protobufs are not appropriate for a use case, or even not appropriate outside Google except in limited circumstances (e.g. if you don’t have a monorepo)
But he’s missing the whole point, and hasn’t worked on anything nontrivial that uses protobufs
I would go look at what this person has actually built, and then go look at what people have built with protobufs. (I didn’t actually go look, but I can already tell by the way this article is written)
He doesn’t know what he doesn’t know
iirc OP literally worked at Google, so i feel like dismissing the criticism as one that comes from lack of exposure probably isn’t reasonable.
what would advise to use instead? if anything
We use JSON-RPC ( https://www.jsonrpc.org/specification ) - which is really just a loose standard around formatting an RPC call over the wire as JSON. We don’t have any regrets going with that over gRPC (which was the only real other alternative when we picked it). I like that it covers virtually all use cases you’d need, is easy to hand-write when necessary, and (with a bit of TypeScript or JSDoc) can give you most of the benefits that you get immediately without moving into the realm of diminishing returns.
Cap’n Proto is supposed to be a huge improvement over protobufs, though I haven’t used it myself:
https://capnproto.org/
FlatBuffers seem popular as a replacement. I’ve not used them but some teams 8 worked with moved to them and found that they were fast and simple to use.
If connectrpc supported flatbuffers, I would definitely use that instead of protos.
I’ve meant to write a rebuttal to this for years, but I think it’s a question of framing. If you frame it about as describing a language (ie: a grammar for serialising a particular type) then it makes a little more sense. The whole issue is that he’s trying to cram an ADT style worldview (which is relatively tightly coupled, but that’s okay because it’s in-process) into a distributed world, where versioning is a problem.
I definitely prefer it over openapi’s type syntax/system.
I appreciate this comment, when I started reading the article, I thought “I wonder what technomancy would say about gRPC”.
TBH the biggest problem with gRPC is A) protobufs are bad and B) most people conflate gRPC and protobuf without realizing you can replace the encoding with a better one.
I honestly don’t have a problem with gRPC on its own, provided it’s used with a good encoding.
The main mistake of gRPC is its use of HTTP trailers which blunders into a huge pile of nasty interop problems.
I’m on the other end of this (been using gRPC and loving it – mainly the end-to-end type safety), what made it suck in your experience, and what alternatives did you look at that might be better?
I find it darkly humorous that one of the downsides of using gRPC-web is that it doesn’t work well with the Chrome devtools.
Like, really? Out of all the monopolistic shit Google has pulled with Chrome, not including gRPC tooling (even if only for their own internal users) in devtools was a red line in the sand for them? (If this company felt it was a problem, Google engineers presumably did as well.)
gRPC is a standard way of working, so if. you adopted a standard way of working, and it worked, that’s awesome. But that isn’t an inherent advantage of gRPC. It’s the advantage of saying “We’re going to work like this” and meaning it.
You could accomplish the same with Avro and Kafka, or JSON Schema and HTTP, so long as you all work in accordance with the agreed standard way of working.