Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Protobuf Editions are here: don't panic

buf.build

Post reply on HN
Print view View original

51–58 of 58 posts

Re: Protobuf Editions are here: don't panic

#51

Post by dilyevsky »

swatcoder wrote: post #42
hot_gril wrote: post #38

Earlier quoted context omitted.

They're comparable for a lot of use cases. In fact many protobuf-based APIs will also have a JSON mode.

Exactly because the consumers of those API's exhibit a strong preference for one or the other. Library/module/API developers often seek to deliver maximimum adaptibility in their interfaces so that consumers of them can satisfy their own more specific/pressing requirements.

imo it's mainly because protos are unusable on the web without something like grpc-web (which requires a proxy) and in general web support in protobufs always seemed like an afterthought, just barely working (if at all) which is kind of ironic considering it came out of Google

Re: Protobuf Editions are here: don't panic

#52

Post by jsnell »

akshayshah wrote: post #20
jsnell wrote: post #12

Earlier quoted context omitted.

Where are you getting this nonsense from, and if you're just speculating, why are you stating it with such confidence as a fact? Protobufs predate Go by more than half a decade, and there is no overlap between the authors.

Per multiple sources, including the team currently maintaining the Protobuf toolchain within Google, proto3 was largely designed by Rob Pike. Of course the Protobuf wire format is quite a bit older, but some aspects of proto3 and Go's shared semantics (like implicit zero values) do seem to have come from the same mind.

That's a much smaller claim, proto3 schemas are a fairly minor evolution over proto2 schemas, mostly removing features. My impression was always that it was either removing things that were expensive to support in Javascript, impossible to serialize to idiomatic JSON, or that the team thought were misfeatures that nobody should ever use. That's a far cry from the original claim that Go and protobufs were co-designed "in the same meetings".

But even that limited claim is kind of hard to believe. Can you link to one of those multiple sources making that claim?

Re: Protobuf Editions are here: don't panic

#53

Post by hot_gril »

dilyevsky wrote: post #51
swatcoder wrote: post #42

Earlier quoted context omitted.

Exactly because the consumers of those API's exhibit a strong preference for one or the other. Library/module/API developers often seek to deliver maximimum adaptibility in their interfaces so that consumers of them can satisfy their own more specific/pressing requirements.

imo it's mainly because protos are unusable on the web without something like grpc-web (which requires a proxy) and in general web support in protobufs always seemed like an afterthought, just barely working (if at all) which is kind of ironic considering it came out of Google

I've never used protobufs with web, but I don't see why not. gRPC, on the other hand, requires HTTP/2 which can be a luxury. I remember making a side project that uses gRPC a while ago and trying to deploy on GCP AppEngine, only to find out it doesn't support gRPC.

Re: Protobuf Editions are here: don't panic

#54

Post by dilyevsky »

hot_gril wrote: post #53
dilyevsky wrote: post #51

Earlier quoted context omitted.

imo it's mainly because protos are unusable on the web without something like grpc-web (which requires a proxy) and in general web support in protobufs always seemed like an afterthought, just barely working (if at all) which is kind of ironic considering it came out of Google

I've never used protobufs with web, but I don't see why not. gRPC, on the other hand, requires HTTP/2 which can be a luxury. I remember making a side project that uses gRPC a while ago and trying to deploy on GCP AppEngine, only to find out it doesn't support gRPC.

well if you can't use gRPC which, as you correctly notes, is protocol-incompatible with browser APIs, you kinda need to roll your own RPC framework. Various attempts had been made at this - see connectrpc, for example, by the same company that authored this post. imo, big advantage of protobuf/gRPC ecosystem is that Google is doing all the heavy lifting for you, so unless something else catches on with wider community it's going to be pretty risky beyond hobby projects.

Re: Protobuf Editions are here: don't panic

#55

Post by rco8786 »

hot_gril wrote: post #53
dilyevsky wrote: post #51

Earlier quoted context omitted.

imo it's mainly because protos are unusable on the web without something like grpc-web (which requires a proxy) and in general web support in protobufs always seemed like an afterthought, just barely working (if at all) which is kind of ironic considering it came out of Google

I've never used protobufs with web, but I don't see why not. gRPC, on the other hand, requires HTTP/2 which can be a luxury. I remember making a side project that uses gRPC a while ago and trying to deploy on GCP AppEngine, only to find out it doesn't support gRPC.

> I've never used protobufs with web, but I don't see why not

We have a bunch of apis like this where I work. It's a huge pain, tbh. You lose the ability to just curl endpoints, or to see what data came over the wire for debugging, not to mention having to use esoteric client libs because every off-the-shelf one just assumes json over http.

Re: Protobuf Editions are here: don't panic

#56

Post by VHRanger »

TillE wrote: post #40
VHRanger wrote: post #33

Earlier quoted context omitted.

JSON with a good schema if you're doing it across languages?

I'm sure there's some great schema implementation that you can bolt onto JSON, but personally I have never seen anyone actually using one in the wild. With protobuf the schema is essential, it is the foundation. I feel this is a huge advantage especially for communication protocols.

We've used it. It's useful to define the contract between teams.

So you have 2 teams do a meeting, we work out a contract we like, dump that into a jsonschema and you can enforce by unit tests that schema is respected on each side (producer/consumer)

Re: Protobuf Editions are here: don't panic

#57

Post by hot_gril »

dilyevsky wrote: post #54
hot_gril wrote: post #53

Earlier quoted context omitted.

I've never used protobufs with web, but I don't see why not. gRPC, on the other hand, requires HTTP/2 which can be a luxury. I remember making a side project that uses gRPC a while ago and trying to deploy on GCP AppEngine, only to find out it doesn't support gRPC.

well if you can't use gRPC which, as you correctly notes, is protocol-incompatible with browser APIs, you kinda need to roll your own RPC framework. Various attempts had been made at this - see connectrpc, for example, by the same company that authored this post. imo, big advantage of protobuf/gRPC ecosystem is that Google is doing all the heavy lifting for you, so unless something else catches on with wider communit…

Yeah, that's why I wouldn't do it. Not totally unusable, but painful.

Re: Protobuf Editions are here: don't panic

#58

Post by b33j0r »

intelVISA wrote: post #24
b33j0r wrote: post #9

Earlier quoted context omitted.

Because the same group in google developed both, indeed. They were developed as a microservice high-performance lang, compiler, and serialization protocol in the same meetings.

You WILL accept The One Right Way to write code and serialize data! -rob pike Do wake me when they get around to adding the 'high performance' lang part though. Wild how all this ecosystem junk originates from a few early Googlers' fear of learning beautiful C.

Just for posterity, I actually agree with you, and was representing the history of our situation. Not my own opinions. “High performance” absolutely means “buzzword.”

I can attest that the intentions were good, and it’s another tool in our toolbox. A good one, but not the silver bullet sometimes some said.

Post reply on HN