No access to Env in #[wasm_bindgen] RPC functions

[ilijaljubicic]

It seems it is currently not possible to access the Env inside functions exposed via #[wasm_bindgen] and used in Workers RPC. This limitation makes it difficult to use RPC endpoints for any functionality that depends on environment bindings (e.g., Hyperdrive, secrets, KV, etc.).

#[wasm_bindgen]
pub async fn add(a: u32, b: u32) -> u32 {   
    // Access Env somehow....
    a + b
}

There should be a way to access the Env, similar to how it is provided to the fetch handler.

[spigaz]

This reference might be what you are looking for

The env object is exposed as a class property of the WorkerEntrypoint class

that you will have to extend

  async greet(name) {
    return this.env.GREETING + name;
  }

https://developers.cloudflare.com/workers/runtime-apis/bindings/service-bindings/rpc/

workers-rs is just a wrapper over the plain js implementation.

So what is missing, is a wrapper to what is already exposed by the js, that you probably can add by yourself.

In practice I have no idea of the current RPC support status in workers-rs.

[ilijaljubicic]

@spigaz thank you for pointing out to the right direction.

I did check existing RPC implementation that is still experimental and also took a freedom to open a PR that is solving this Env issue and opening a space for future additions.

I did test it locally and it works, since there were no existing tests cases for the RPC functionality, I was a bit lost on how to implement test for it.

What I am not sure if inside shim.js it should use async and await, I assumed not because CF RPC implementation uses custom then-ables and should allow for streaming results but also in future to send back functions and classes.
There is actually this open issue with using ByteStream #711 , I plan to try something similar with new RPC implementation.

This is the PR that implements rpc macro.

It is taking approach similar to durable objects (kind of) by introducing #[rpc] on required implementation and methods that should be registered as RPC methods. It is generating main struct that is getting implementation to reduce chances for bugs.
Not sure if the best approach, maybe is better to require defining also main struct but not sure how to guarantee later inside shim.js that there is fn new that takes Env as an argument so it can be injected in the runtime.

[spigaz]

@ilijaljubicic To be honest I don't know, but you might get some help / insights on discord, I'm guessing more likely in the non rust channels.

Many times I have noticed that although irresponsive here, many devs in those channels, including CF's, do know rust pretty well and the best way to implement the rust part.

I wish we were able to solve this, as I need to use this also, but I already have a PR open, for months now, and another in the pipeline...

[ilijaljubicic]

Yes, good, idea, will consult on discord, though after further check, I am more confident now that implementation in the PR is ok in regards not to use 'async function; for the injected RPC method nor to await for the wrapped function ( in the shim.js)

        Entrypoint.prototype[methodName] = function (...args) {
          const rpc = this._getRpc(Ctor);
          return rpc[methodName](...args);
        };

From doc:

Whether or not the method you are calling was declared asynchronous on the server side, it will behave as such on the client side. You must await the result.

Sync example from the doc:

export default class extends WorkerEntrypoint {
  async fetch() { return new Response("Hello from Worker B"); }

  add(a, b) { return a + b; }
}

In the RPC client worker, it has to be awaited:

const result = await env.WORKER_B.add(1, 2);

Async example from the doc:

export default class extends WorkerEntrypoint {
  async fetch() { return new Response("Hello from counter-service"); }

  async newCounter() {
    let value = 0;
    return (increment = 0) => {
      value += increment;
      return value;
    }
  }
}

In RPC client worker both main method and inner method has to be awaited:

export default {
  async fetch(request, env) {
    using f = await env.COUNTER_SERVICE.newCounter();
    await f(2);   // returns 2
    await f(1);   // returns 3
    const count = await f(-5);  // returns -2

    return new Response(count);
  }

In the Workerd runtime, the result will be automatically wrapped in a thenable, it is handed by workerd runtime:

Note that RPC calls do not actually return Promises, but they return a type that behaves like a Promise. The type is a "custom thenable", in that it implements the method then(). JavaScript supports awaiting any "thenable" type, so, for the most part, you can treat the return value like a Promise.