4 ms·
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
by seattleeng 8y ago
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 https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-WEB.md
- thwd 8y agoHTTP/2 is only necessary if you want to stream, most of gRPC can be implemented over traditional request/response cycles.
- Matthias247 8y agoTechnically 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.