3 ms·

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

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.

jchw 4y ago
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.
- akshayshah 4y ago
  I’m tracking a similar issue in https://github.com/bufbuild/connect-go/issues/222 https://github.com/bufbuild/connect-go/issues/222 - is this roughly what you’re looking for?
  - jchw 4y ago
    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.
akshayshah 4y ago
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!)
- yencabulator 4y ago
  > 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/ 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 https://bugs.chromium.org/p/chromium/issues/detail?id=688906

jchw 4y ago

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.

akshayshah 4y ago
I’m tracking a similar issue in https://github.com/bufbuild/connect-go/issues/222 https://github.com/bufbuild/connect-go/issues/222 - is this roughly what you’re looking for?
- jchw 4y ago
  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.

akshayshah 4y ago

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!)

yencabulator 4y ago
> 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/ 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 https://bugs.chromium.org/p/chromium/issues/detail?id=688906