Hacker News Reader

Comment by xyzzy_plugh | Hacker News Reader

I think everything gRPC can do, Connect can do too, either via gRPC or its own protocol. Given browser support is planned, I think the "in some conditions" you refer to is basically the browser using HTTP/1.1. I imagine they'll support a websocket driver for true bidirectional streaming.

> I recall having a lot of trouble with figuring out whether gRPC would handle streaming connections hanging gracefully, for example.

I think I know what you mean, I've always had a hard time differentiating from protocol errors and application errors. Ultimately I gave up trying to be smart and just treated any interruption the same way: resume the stream from where it left off. Transactional behavior is impossible within just gRPC, as far as I can tell.

View on HN

Basically, yes! Browsers aren't the only clients (or servers) with limited capabilities, but they're probably the most important. Funnily enough, the biggest problem with browsers & gRPC isn't HTTP/2, its support for HTTP trailers.

I'm bemused by gRPC's status code system. It seems just as difficult to use as HTTP status codes, more or less, while also being less widely understood. If I were designing for myself, there would only be four error codes: maybe retriable and definitely not retriable, with an extra bit for whether or not the application returned the code explicitly. Sadly, we had to adopt gRPC's codes to make multi-protocol support work well. (Plus, I don't think anyone else agrees with my hot take on errors!)

> the biggest problem with browsers & gRPC isn't HTTP/2, its support for HTTP trailers.

Browser fetch also doesn't support streaming request body (on current day browsers)

https://web.dev/fetch-upload-streaming/ "It doesn't look like your browser supports request streams."

https://bugs.chromium.org/p/chromium/issues/detail?id=688906

Yeah, I suppose if you can just use ordinary gRPC, this is basically not a real problem. I’ll definitely want to take a look at the API to see if it improves on the confusion I ran into with upstream gRPC Go. The inability to do “transactional” stuff with gRPC isn’t really a deal breaker, I just want good error handling and recovery.

I’m tracking a similar issue in https://github.com/bufbuild/connect-go/issues/222 - is this roughly what you’re looking for?

Yeah, I think so. I’m a bit fuzzy on the details as I haven’t been working with gRPC in a little bit now. But that seems like it would solve the problem, to me.

Reply on news.ycombinator.com