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

Why does gRPC insist on trailers?

carlmastrangelo.com

Post reply on HN
Print view View original

131–136 of 136 posts

Re: Why does gRPC insist on trailers?

#131

Post by twic »

chucke wrote: post #129
twic wrote: post #112

Earlier quoted context omitted.

I've used SSE and websockets a lot. I like SSE. But it has two key weaknesses compared to websockets. Firstly, it's unidirectional. The server sends a stream of events to the client, but the client can't send anything back. That might not be a problem at a purely semantic level (maybe the client doesn't have anything to send back), but it means you can't implement application-level heartbeating or flow control in-ban…

Both downsides are fixed by using http/2, right? Heartbeat seems trivial to implement using HTTP/2 PING frame. And you already mentioned the stream sharing, which IMO is much better than the state of each tab on the same website opening its own TCP socket, pretty much a resource exhaustion hell (browsers didn't implement websockets on top of h2 last time I checked). Websockets do have an advantage over SSE: they get…

HTTP/2 doesn't fix the former downside. It doesn't give you a general bidirectional stream, so you can't implement flow control. I'm not aware of a browser API for sending (or inhibiting) HTTP/2 pings - is there one? In the absence of one, you also can't use HTTP/2 to implement an application-level heartbeat.

To expand on this a bit, a problem i have run into with SSE is that the socket is open, some part of the client (the browser or HTTP client) is reading data, but it is not being processed, because the actual application code on the client is stuck or broken or something. To deal with that, you have to be able to drive feedback from the application code on the client to the server.

Re: Why does gRPC insist on trailers?

#132

Post by modeless »

guenthert wrote: post #128
modeless wrote: post #43

Earlier quoted context omitted.

It's clear that the "single engineer" thing is a lie. Many engineers commented on the Chrome issue with opposing viewpoints, and even the original post describes it being escalated to tech leads on both sides, getting more people involved. I guarantee if it was only one person standing alone opposed to trailers then they would have been overruled. As you say, it's a good thing that Chrome resists adding the pet featu…

Jeebus. Just because it's not true doesn't mean it's a lie.

It's a lie if OP knows it isn't true. And OP knows it isn't true because they explicitly describe a lot more than one person being involved on both sides.

Re: Why does gRPC insist on trailers?

#133

Post by Thorrez »

candiodari wrote: post #130
Thorrez wrote: post #125

Earlier quoted context omitted.

That has the downside that you're now limiting what protobuf payloads you can send. You need to have the inner protocol (protobuf) cooperate with the outer protocol. That also makes it difficult to switch to a different type of payload besides protobuf, since even if you could convince the protobuf standard to reserve a specific key for the outer protocol, you might not be able to convince the standard for a differen…

I think most people would say that not being able to use GRPC at all on the web is not exactly the superior option/outcome ... I'm not sure why a "pure design" (non-mixed layers) matters when the result is non-functional. Just open a second websocket for the second protocol. Or use WebRTC. Or ... most protocols have these channels, which means mixing payloads is not really that useful. It doesn't buy you anything ove…

I'm not saying the current situation is better than your suggestion. I'm saying there are better ways to fix the current situation than your suggestion.

My idea of a better way would be:

* If you just need a boolean of success vs failure: use END_STREAM vs RST_STREAM.

* If you additionally need metadata of failure reason: use the existing length prefixes that gRPC has, and additionally add a bit to indicate data vs trailer. Then implement your own trailers inside the HTTP2 stream to indicate success vs failure and failure reason. Sure these trailers won't get HTTP2 compression like native HTTP2 trailers, but that shouldn't be a big problem.

Using 2 websockets would be confusing because things could arrive out of order from how they were sent. And one websocket could fail but not the other, leading to a confusing mixed state. The whole reason for trailers was to make failures less confusing by having error messages in them.

Also, using websockets goes against the whole gRPC design idea. They wanted native HTTP2. We don't need websockets to fix the problem, we just need to implement trailers inside the stream instead of using native HTTP2 trailers. Implementing trailers inside the stream can be done with native HTTP2 streams or with websockets inside HTTP2 streams. It's a smaller change from the current protocol to put the trailers inside the native HTTP2 stream than to add websockets to the mix then implement trailers inside that.

Re: Why does gRPC insist on trailers?

#134

Post by rswail »

atombender wrote: post #123
rswail wrote: post #76

Personal opinion: RPC is a failed architectural style, independent of what serialization/marshalling of arguments is used. it failed with CORBA, it failed with ONC-RPC, it failed with Java RMI. Remote Procedure Calls attempt to abstract away the networked nature of the function and make it "look like" a local function call. That's Just Wrong. When two networked services are communicating, the network must be consider…

CORBA and RMI are quite different from gRPC. (I have not used ONC-RPC.) Both of those are explicitly centered on objects and locality transparency. The idea is that you get back references to objects, not mere copies of data. Those references act as if they're local, but the method calls actually translate into RPC calls, as the local reference is just a "stub". Objects can also contain references, meaning that you a…

I don't "believe" in REST, except that when you do it "properly" with media types and links, and proper thought about the resources you identify and what the state transitions are, it all works very nicely as a request/response API style.

The difference is during the design phase, where you focus on those resources and their state, instead of the process for changing that state.

Re: Why does gRPC insist on trailers?

#135

Post by mdriley »

lakomen wrote: post #92
mdriley wrote: post #49

It seems like a lot of other technologies in this space have solved the listed problems while remaining compatible with browsers, load balancers, reverse proxies, etc. It was a product choice not to offer a fallback path when HTTP/2 was unavailable. That choice made gRPC impossible to deploy in a lot of real-world environments. What motivated that choice?

Can you name one or more?

one relevant datapoint: https://devblogs.microsoft.com/dotnet/announcing-grpc-json-t...
Post reply on HN