cloudflare
Need support gRPC-web proxy to gRPC, just like envoy does.
What is the problem your feature solves, or the need it fulfills?
Need support gRPC-web proxy to gRPC, just like envoy does.
A clear and concise description of why this feature should be added. What is the problem? Who is this for?
Describe the solution you'd like
What do you propose to resolve the problem or fulfill the need above? How would you like it to work?
Describe alternatives you've considered
What other solutions, features, or workarounds have you considered that might also solve the issue? What are the tradeoffs for these alternatives compared to what you're proposing?
Additional context
This could include references to documentation or papers, prior art, screenshots, or benchmark results.
There are several startup teams around us that have started using gRPC-web intensively. The core reason is that the IDL-generated code can save a lot of time previously spent on interface debugging and alignment between front-end and back-end fields, significantly boosting development efficiency. However, support for gRPC-web is still quite limited. The viable options currently available are as follows:
- Envoy Proxy: Using standard gRPC behind the proxy, but this setup feels awkward. The C++ gateway makes refactoring almost unfeasible, and the configuration for wasm support is also cumbersome.
- Tonic: A promising solution we had intended to use, but they are currently undergoing an upgrade to hyper-1.0, which has rendered many parts of the framework unusable. This has led us to look for alternatives to Tonic, and we've come to realize that the team behind Tonic is relatively slow-moving and small.
- Armeria: The only gRPC-web supported framework in the JVM ecosystem, which can be used with Spring, but it also has its quirks. In summary, we believe that the new development workflow represented by gRPC-web fundamentally solves many of the challenges faced during joint debugging between front-end and back-end teams. Unfortunately, Google often introduces concepts without fully nurturing them, leading to a great idea not being implemented at a high level for a long time, which is regrettable. We believe add supporting to grpc-web will make pingora more successful in the brave new future.
Need support gRPC-web proxy to gRPC, just like envoy does.
Specifically do you want gRPC-web client bridging? Or the reverse bridge Envoy supports (gRPC client to gRPC-web server).
Service-side reverse proxies like Envoy are generally better， because client bridging solutions based on JavaScript are almost impossible. This is because the standard gRPC relies on HTTP/2, but JavaScript clients cannot force the server to support HTTP/2. This depends both on server-side support and browser support, making it nearly impossible to achieve consistency. However, with server-side reverse proxies like Envoy, there are no such technical obstacles.
To be clear I mean
grpc_http1_bridge filter which allows gRPC requests to be sent to Envoy over HTTP/1.1. Envoy then translates the requests to HTTP/2 or HTTP/3 for transport to the target server. The response is translated back to HTTP/1.1.
vs
grpc_http1_reverse_bridge filter which allows gRPC requests to be sent to Envoy and then translated to HTTP/1.1 when sent to the upstream. The response is then converted back into gRPC when sent to the downstream.
It sounds like you want Envoy's grpc_http1_bridge functionality.
We actually have similar functionality internally for gRPC-web (not application/grpc-web-text). I’ll look into exposing this as a module.
Sorry for the delay, haven't forgot about this. There's a change in review internally that provides this functionality as a module, should land soonish.