Can tonic-web act as a standalone gRPC-Web reverse proxy for non-tonic backends?
#2787
ContextFor the past few years, my team and I have been building full-stack web apps backed by a C++ gRPC server. To bridge browser HTTP/1.1 requests to gRPC over HTTP/2, we currently use the Golang gRPC Web Proxy. That setup works, but it has platform limitations for us:
I recently started using QueryFrom what I understand, Can In other words, can it be used as a drop-in replacement for the Go gRPC-Web Proxy without requiring the backend server itself to be written in Rust/tonic? |
Replies: 1 comment 1 reply
|
Yes, and I verified it end to end against a non-Rust backend before writing this. tonic-web does not ship a standalone proxy binary, but its translation layer is fully decoupled from tonic services, so about sixty lines of glue turn it into exactly the drop-in you describe, as an embeddable Rust library rather than a process you shell out to, which addresses both your MSVC and Android constraints. The decoupling is visible in the trait bounds. In impl<S, ReqBody, ResBody> Service<Request<ReqBody>> for GrpcWebService<S>
where
S: Service<Request<Body>, Response = Response<ResBody>>,
ReqBody: http_body::Body<Data = bytes::Bytes> + Send + 'static,
ResBody: http_body::Body<Data = bytes::Bytes> + Send + 'static,The inner That forwarder is small. The essential part: #[derive(Clone)]
struct GrpcForward {
client: Client<HttpConnector, TonicBody>, // hyper-util client, http2_only(true)
backend: Authority, // e.g. 127.0.0.1:50051
}
impl tower::Service<Request<TonicBody>> for GrpcForward {
type Response = Response<hyper::body::Incoming>; // Incoming preserves trailers
// poll_ready: Ready; call: rewrite scheme+authority to the backend,
// keep the /package.Service/Method path, client.request(req)
}
let proxy = GrpcWebLayer::new().layer(GrpcForward { client, backend });
// serve with hyper-util auto::Builder (accepts HTTP/1.1 and h2) + TowerToHyperServiceThis compiles against the current workspace with no protoc anywhere, and I ran the full path rather than trusting the types. Backend: a pure Python grpcio server using a generic raw-bytes handler, so no protobuf and no Rust on that side, standing in for your C++ service. Client: curl over HTTP/1.1 posting a handcrafted gRPC-Web frame (0x00 flag, 4-byte length, payload) with Caveats so you can judge fit against grpcwebproxy:
Since the listener is just a tokio task, the same code embeds directly in a |
|
Thank you so much! This worked perfectly. I've attached my implementation of this in-case anyone else is interestted: gRPC Web Proxyuse std::task::{Context, Poll};
use http::{Request, Response, Uri};
use hyper::body::Incoming;
use hyper_util::client::legacy::connect::HttpConnector;
use hyper_util::client::legacy::Client;
use hyper_util::rt::TokioExecutor;
use tonic::body::Body as TonicBody;
use tonic_web::{GrpcWebLayer, GrpcWebService};
use tower::{Layer, Service};
/// gRPC-Web to gRPC proxy for external gRPC servers
///
/// `GrpcWebProxy` is the transport bridge used by the host to forward requests from an HTTP/1.1 gRPC-Web
/// endpoint into an external backend gRPC server over HTTP/2.
///
/// The proxy is intentionally payload-agnostic:
/// - It does not decode protobuf messages.
/// - It preserves request headers/body and response body/trailers.
/// - It only rewrites the request URI authority/scheme to target the selected plugin backend.
///
/// `GrpcWebLayer` is applied in [`new`](Self::new), so callers receive a ready-to-mount gRPC-Web service.
#[derive(Clone)]
pub struct GrpcWebProxy {
/// HTTP/2 client used to reach plugin upstreams.
client: Client<HttpConnector, TonicBody>,
/// Upstream authority in host:port form.
authority: http::uri::Authority,
}
impl GrpcWebProxy {
/// Builds a gRPC-Web capable proxy service.
///
/// # Arguments
/// - `authority`: Upstream plugin gRPC endpoint as `host:port` (for example `127.0.0.1:50051`).
///
/// # Returns
/// A `GrpcWebService<Self>` ready to mount in an Axum router.
///
/// # Notes
/// This constructor enforces an HTTP/2-only client for upstream communication.
/// CORS and error-to-response adaptation are intentionally left to the caller's outer middleware stack.
///
/// # Errors
/// Returns an error when `authority` is not a valid HTTP authority value.
pub fn new(authority: &str) -> Result<GrpcWebService<Self>, Box<dyn std::error::Error>> {
let authority = authority.parse::<http::uri::Authority>()?;
let mut connector = HttpConnector::new();
connector.enforce_http(false);
let client = Client::builder(TokioExecutor::new()).http2_only(true).build(connector);
let forwarder = Self { client, authority };
let proxy = GrpcWebLayer::new().layer(forwarder);
Ok(proxy)
}
}
impl Service<Request<TonicBody>> for GrpcWebProxy {
type Response = Response<Incoming>;
type Error = hyper_util::client::legacy::Error;
type Future = <Client<HttpConnector, TonicBody> as Service<Request<TonicBody>>>::Future;
fn poll_ready(&mut self, _cx: &mut Context<'_>) -> Poll<Result<(), Self::Error>> {
// The underlying hyper client is cloneable and immediately ready for dispatch.
Poll::Ready(Ok(()))
}
fn call(&mut self, req: Request<TonicBody>) -> Self::Future {
let (mut parts, body) = req.into_parts();
let path_and_query = parts.uri.path_and_query().map(|pq| pq.as_str()).unwrap_or("/");
let upstream_uri = Uri::builder()
.scheme("http")
.authority(self.authority.as_str())
.path_and_query(path_and_query)
.build()
.expect("valid upstream URI");
// Preserve method, headers, and path while retargeting the request to the external server backend.
parts.uri = upstream_uri;
// Forward raw body frames so tonic-web can translate framing/trailers for browser clients.
self.client.call(Request::from_parts(parts, body))
}
}How to uselet route = "/api/grpc";
let grpc_web_proxy = GrpcWebProxy::new(addr.as_str())?;
// `nest_service` only accepts services whose error type is `Infallible`. The gRPC-Web proxy can fail
// with upstream transport errors, so we map those failures into an HTTP 502 response to satisfy Axum's
// trait bound and return a predictable client-facing error when an external backend is unavailable.
let grpc_web_proxy =
HandleError::new(grpc_web_proxy, |_err: hyper_util::client::legacy::Error| async move {
(StatusCode::BAD_GATEWAY, "Plugin gRPC upstream unavailable")
});
router = router.nest_service(&route, grpc_web_proxy); |
Yes, and I verified it end to end against a non-Rust backend before writing this. tonic-web does not ship a standalone proxy binary, but its translation layer is fully decoupled from tonic services, so about sixty lines of glue turn it into exactly the drop-in you describe, as an embeddable Rust library rather than a process you shell out to, which addresses both your MSVC and Android constraints.
The decoupling is visible in the trait bounds. In
tonic-web/src/service.rs(v0.14.6, lines 70-76):