3 ms·

Can someone describe why gRPC-Web needs a proxy? I recently had trouble deciding between the official gRPC-Web and Improbable's gRPC-Web[1]. In the end I decid

Can someone describe why gRPC-Web needs a proxy? I recently had trouble deciding between the official gRPC-Web and Improbable's gRPC-Web[1]. In the end I decided on Improbable's, because it seemed to not require a proxy. In practice, it's working very nicely. Yet, I'm still not clear on what exactly the Proxy serves to do, in either case. If a browser supports HTTP 2, why is a proxy needed? [1]: https://github.com/improbable-eng/grpc-web https://github.com/improbable-eng/grpc-web

deleted 8y ago
[deleted]
bpicolo 8y ago
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#local-proxies https://github.com/grpc/grpc-web/blob/master/ROADMAP.md#loca...
- asdkhadsj 8y ago
  Ah hah! Thanks! Yea the drop-in web server works awesomely. It's been a surprisingly painless experience. Thanks for linking the roadmap!
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 ago
  HTTP/2 is only necessary if you want to stream, most of gRPC can be implemented over traditional request/response cycles.
  - Matthias247 8y ago
    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.
hsaliak 8y ago
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.
- thwd 8y ago
  Note that trailers have existed since HTTP 1.1.
  - puzzle 8y ago
    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.
  - chrissnell 8y ago
    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.
    - mentat 8y ago
      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.
      - aktau 8y ago
        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.
deleted 8y ago
[deleted]

deleted 8y ago

[deleted]

bpicolo 8y ago

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#local-proxies https://github.com/grpc/grpc-web/blob/master/ROADMAP.md#loca...

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

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 ago
HTTP/2 is only necessary if you want to stream, most of gRPC can be implemented over traditional request/response cycles.
- Matthias247 8y ago
  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.

hsaliak 8y ago

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.

thwd 8y ago
Note that trailers have existed since HTTP 1.1.
- puzzle 8y ago
  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.
- chrissnell 8y ago
  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.
  - mentat 8y ago
    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.
    - aktau 8y ago
      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.

deleted 8y ago

[deleted]