gRPC needs access HTTP/2 trailers, which is not supported in browsers today. This necessitates translation in a proxy of some form. It is possible to support in-process or local proxies, but instead starting with this in n languages, we are starting with a proxy, with the intention to build in-process support on languages or use cases where there is real need for it.

I never understood why gRPC decided to use HTTP2 instead of WebSockets. WebSockets is a much simpler protocol and is the closest you can get to raw TCP sockets in the browser.

HTTP was designed for file downloads and uploads while. WebSockets was designed for raw data.

Note that trailers have existed since HTTP 1.1.

The answer--as I recall--from the Chromium team was that they see trailers access as a security issue. HTTP/2 multiplexes many connections and it was a security risk, they said, to allow one client process to access trailers for connections that may be used by different processes or even entirely different sites behind the same load balancer/reverse proxy/etc.

What I don't understand is why gRPC was designed to depend on trailers. Web gRPC is the killer app for this technology. If they could build a new version of the protocol that doesn't rely on trailers, I would be thrilled.

I believe trailers are because you could start streaming a response and end up having an error than you need to communicate out of band. Hopefully someone has a better answer though.

I've been trying to read the HTTP2 spec and I can't figure out whether it's allowable to return or modify the HTTP(2) status code in a trailer instead of in the header.

After some re-readings, I decided it wasn't allowed.

But then, gRPC definitely needs to be able to signal an error even after it has already streamed data. So gRPC would need to use some end-of-connection message, like a trailer.

Yeah, but a lot of software does not support them, at all levels in the chain. Which is a tragedy. They'd be useful in more contexts than just gRPC.

improbable/grpc-web does require a proxy, it just happens to also support a drop-in http proxy in the same app when you're writing a golang based grpc app.

grpc/grpc-web intends to support the same: https://github.com/grpc/grpc-web/blob/master/ROADMAP.md#loca...

Ah hah! Thanks! Yea the drop-in web server works awesomely. It's been a surprisingly painless experience. Thanks for linking the roadmap!

Conceptually, I think you're right -- to serve gRPC requests only requires http2 as a transport and more shouldn't be necessary (edit: I stand corrected, seems like not all HTTP2 features are supported by all modern browsers). In practice, I believe the official gRPC web setup it serves as a translation layer and provides some monitoring bells and whistles. E.g. the official gRPC-Web implementation allows for a base-64 encoded wire format in addition to the typical protobuf binary format, so without a proxy layer, you'd need to define middleware server-side that translates the base64 encoding to the protobuf format.

I think the full set of differences can be found here: https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-WEB.md

HTTP/2 is only necessary if you want to stream, most of gRPC can be implemented over traditional request/response cycles.

Technically it's not even required for that. HTTP/1.1 bodies can be streamed just fine. The main reason not to do this in a browser is that one real TCP connection would be required for each stream, and the number of concurrent outgoing connections from a website is strictly limited. With HTTP/2 this problem goes away.