Author doesn't support the case for grpc being a "failure". I wonder by what measure. It's certainly pretty popular.
[deleted]
Why does gRPC insist on trailers?
11–20 of 136 posts
Re: Why does gRPC insist on trailers?
#12Relevant post from a few days ago:
Connect-Web: TypeScript library for calling RPC servers from web browsers
https://news.ycombinator.com/item?id=32345670
I’m curious if anyone knows how Google internally works around the lack of support for gRPC in the browser? Perhaps gRPC is not used for public APIs?
The lack of browser support in the protobuf and gRPC ecosystem was quite surprising and one of the biggest drawbacks noted by my team while evaluating various solutions.
Re: Why does gRPC insist on trailers?
#13> Why Do We Need Trailers At All?
The author convinced they're needed. But I wonder if some sort of error signaling should have been baked into `Transfer-Encoding: chunked` instead. It wouldn't have made sense in HTTP/1.1 since you can just close the connection. But in later HTTP versions with pipelined requests, I can see the use for bailing on one request while keeping the rest alive.
Re: Why does gRPC insist on trailers?
#14Great article. I really like the points in "Lessons for Designers" section. Applicable for software engineering in general as well.
Re: Why does gRPC insist on trailers?
#15Relevant post from a few days ago: Connect-Web: TypeScript library for calling RPC servers from web browsers https://news.ycombinator.com/item?id=32345670 I’m curious if anyone knows how Google internally works around the lack of support for gRPC in the browser? Perhaps gRPC is not used for public APIs? The lack of browser support in the protobuf and gRPC ecosystem was quite surprising and one of the biggest drawback…
Looks like they have a separate protocol[0] for web compat, and they use a proxy to translate.
[0]: https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-WEB.md
Re: Why does gRPC insist on trailers?
#16> As an aside, HTTP/2 is technically superior to WebSockets. HTTP/2 keeps the semantics of the web, while WS does not. WTF is this? Those are different layer protocols. WebSocket can run on top of HTTP/2. It's like saying TLS is technically superior to TCP, or IP is superior to copper cables. Reference: https://www.rfc-editor.org/rfc/rfc8441.html
> WebSocket can run on top of HTTP/2
Isn't "websocket" just a standard tcp socket, whose specification to instantiate it was born in a comparatively ephemeral HTTP (of whatever version) request, and which outlives the request, so isn't on top of anything other than tcp?
Re: Why does gRPC insist on trailers?
#17Is it still the case that Google Chrome can't support Google gRPC?
It requires a translation proxy: https://github.com/grpc/grpc-web
Re: Why does gRPC insist on trailers?
#18> As an aside, HTTP/2 is technically superior to WebSockets. HTTP/2 keeps the semantics of the web, while WS does not. WTF is this? Those are different layer protocols. WebSocket can run on top of HTTP/2. It's like saying TLS is technically superior to TCP, or IP is superior to copper cables. Reference: https://www.rfc-editor.org/rfc/rfc8441.html
> WebSocket can run on top of HTTP/2 Isn't "websocket" just a standard tcp socket, whose specification to instantiate it was born in a comparatively ephemeral HTTP (of whatever version) request, and which outlives the request, so isn't on top of anything other than tcp?
No, despite the name WebSockets are not plain TCP.
Re: Why does gRPC insist on trailers?
#19I had never heard of HTTP trailers. So FYI > The Trailer response header allows the sender to include additional fields at the end of chunked messages in order to supply metadata that might be dynamically generated while the message body is sent, such as a message integrity check, digital signature, or post-processing status. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Tr...
Haven't headers and trailers been renamed in the recent past?
Re: Why does gRPC insist on trailers?
#20Relevant post from a few days ago: Connect-Web: TypeScript library for calling RPC servers from web browsers https://news.ycombinator.com/item?id=32345670 I’m curious if anyone knows how Google internally works around the lack of support for gRPC in the browser? Perhaps gRPC is not used for public APIs? The lack of browser support in the protobuf and gRPC ecosystem was quite surprising and one of the biggest drawback…
Google internally doesn't have browser grpc clients. It's for service to service rpc and also exposed on googleapis.com apis to third party callers.