gcp_auth icon indicating copy to clipboard operation
gcp_auth copied to clipboard

Adding WASM support

Open sxlijin opened this issue 8 months ago • 1 comments

First off, thanks djc for your work maintaining not only this crate but throughout the Rust HTTP/TLS ecosystem - your name comes up a lot and it's very much noticed and appreciated :)

We're currently using the gcp-auth crate to power our abstractions around calling LLMs, specifically for GCP Vertex. We've currently hand-rolled our gcp auth code on the wasm side, but I was wondering if it would be possible to eventually update (or contribute such updates to) gcp-auth itself to support wasm-bindgen users (e.g. ourselves).

I think the easiest path to do this would be to swap out hyper for reqwest (which has drop-in compatibility, I think with one feature flag, for the js_sys/web_sys impl), but I see some blockers here:

  • It looks like gcp-auth currently directly depends on hyper, although I'm not clear if there's any specific reason it currently uses hyper directly instead of using reqwest under the hood.
  • It also looks like gcp-auth also directly depends on ring, and that one is for significantly less clear reasons.

Let me know if you think this is a welcome direction, if you have other concerns, and what your thoughts are!

sxlijin avatar Mar 21 '25 22:03 sxlijin

We're currently using the gcp-auth crate to power our abstractions around calling LLMs, specifically for GCP Vertex. We've currently hand-rolled our gcp auth code on the wasm side, but I was wondering if it would be possible to eventually update (or contribute such updates to) gcp-auth itself to support wasm-bindgen users (e.g. ourselves).

I think the easiest path to do this would be to swap out hyper for reqwest (which has drop-in compatibility, I think with one feature flag, for the js_sys/web_sys impl), but I see some blockers here:

  • It looks like gcp-auth currently directly depends on hyper, although I'm not clear if there's any specific reason it currently uses hyper directly instead of using reqwest under the hood.

I would rather avoid adding the additional dependencies that reqwest pulls in for non-WASM platforms, but I'd be open to a PR that just uses reqwest on WASM only via some abstraction, maybe like this (from instant-acme):

pub trait HttpClient: Send + Sync + 'static {
    /// Send the given request and return the response
    fn request(
        &self,
        req: Request<Full<Bytes>>,
    ) -> Pin<Box<dyn Future<Output = Result<BytesResponse, Error>> + Send>>;
}
  • It also looks like gcp-auth also directly depends on ring, and that one is for significantly less clear reasons.

It's because the CustomServiceAccount token provider needs to sign a JWT with claims. If you don't need that for your WASM use case, we could probably add a Cargo feature that disables the CustomServiceAccount provider? Or maybe there is some stub for WebCrypto that we can use instead on WASM targets?

First off, thanks djc for your work maintaining not only this crate but throughout the Rust HTTP/TLS ecosystem - your name comes up a lot and it's very much noticed and appreciated :)

Appreciated! Would be awesome if BoundaryML could help sponsor my work, via GitHub or thanks.dev for example.

djc avatar Mar 22 '25 10:03 djc