middleware: changes wasm basic to use waPC

[codefromthecrypt]

Description

Updates wasm basic middleware and simplifies some code inside of it,
notably by using waPC.

This changes the entrypoint function to be named "rewrite" and
uses a pool because known memory allocators are not goroutine
safe.

FYI wazero's first beta tag will be in two weeks
tetratelabs/wazero#506 (comment)

Issue reference

N/A

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• Code compiles correctly
• Created/updated tests
• [n/a] Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]

[berndverst]

@daixiang0 can you review this since you know more about WASM and the Wazero library?

Also we want more information on the structure of the WASM that can be loaded. A compiled WASM sample is obviously not good enough :)

[daixiang0]

@codefromthecrypt thanks for your contribution! Since wazero is not stable now, it will continue to iterate.

Maybe we can get UUID from context. For the logging, I would like to make it detailed to help debug.

Adding more support is my plan, such as support handling HEADER/response changes, while not having much time to do it now.

[codefromthecrypt]

@daixiang0 cool I can do a UUID like https://github.com/wapc/wapc-go/blob/master/engines/wazero/wazero.go#L303

Should we start by assuming the wasm binary changes per request? or should we assume it doesn't?

[daixiang0]

That is an interesting question, load once would get better performance. If wazero supports it, we can use it, and compare SHA256 of the wasm binary, if changes, we reload it.

[codefromthecrypt]

OK I've refactored now, though feels there are some API glitches. Have a look at the impl and if there's any more stuff here I can do that before backfilling tests.

• GetHandler isn't context aware, which can make things like tracing or profiling difficult (initialization logic)
• GetHandler is a func, not an interface, which means what's returned can't be closed. This means some leaks
  • One way is to make Middleware closeable and then move the runtime to a field in that.

[codefromthecrypt]

At least a README should be made in how to generate the wasm

one other thing I think would be helpful is that the "run" function isn't documented or linked in a README or something (at least not that I can find). I think the source that "hello.wasm" was compiled from should be checked in, with instructions on how it was compiled. (ex. tinygo build -o hello.wasm -scheduler=none --no-debug -target=wasi hello.go.

Alternative ABI

Right now, "run" is allocating memory for the URI using tinygo specific allocation. So, ex this won't work with other language compilers. Another way is to not do allocation externally.

WASI-only

Instead of passing memory in and out, you might consider using WASI instead. Doing so would be more portable as you can use other languages.

For example, you can set moduleConfig.args = "rewrite_request_uri", uri and moduleConfig.stdout = buf

then just instantiate the module and see if the stdout is empty or not, and if not assign it to SetRequestURIBytes

WASI+callback

reading stdout is easy, but could result in larger code depending on how people write to it. Another way is to have them call a custom host function if they need to change the URI. So, in this case a host module is instantiated per request which dispatches "set_request_uri(offset, len)" to req.SetRequestURIBytes. The wasm people generate import this function and use that instead of stdout.

Callback only

instead of having the wasm parse os.Args (ex that "rewrite_request_uri" == arg0), the entrypoint function could be like you have now.. "run" aka "rewrite_request_uri". It wouldn't accept any args, as it is hard to know which memory offsets are unused by the compiler. Instead, there's a host function to get the current uri (ex "get_request_uri"). So on each request "rewrite_request_uri" is invoked which might call "get_request_uri" if it was enabled, and then might call "set_request_uri" if it decided to rewrite it.

Your choice here

There's no perfect way, and also there are other tools that have callback flows like wapc. This is mainly to get the thinking down. Even the current approach is fine, if documented. Just it needs tinygo only for wasm generation. That may be fine!

[daixiang0]

Very cool! The basic WASM support is the first step, actually, I am thinking about Envoy WASM ABI implementation, that will create a bridge between service mesh and application runtime. For basic design, I think it is simple enough to start with.

Could you add an example in dapr/examples for this and update related documents?

[codefromthecrypt]

cool. I'll polish this up where basic means URI rewrite. I'll go ahead and update the exported function name to "rewrite_request_uri", also, unless you've strong feelings towards "run"

[daixiang0]

That is good, go ahead!

[codefromthecrypt]

note I hit an unrelated code land mine but back together and will pick this up tomorrow.

[codefromthecrypt]

@daixiang0 I've updated the code here.

Could you add an example in dapr/examples for this and update related documents?

sorry if I'm a bit daft, but can you be precise where you want to update including both the repo and the directory names?

[codefromthecrypt]

trivia

one thing interesting for future work is basically I know of no allocator in wasm that's thread/goroutine safe as they don't use atomics to update the heap. This means that serious performance would rely on a ready pool who have to do one request and either reset or be thrown away. instantiation cost as it is now is ok as the wasm is simple, but even then you should be careful about the memory settings as certain toolchains/compilers reserve a lot of memory by default.

[codefromthecrypt]

@Taction so this is how I am deferring wasi to middleware instantiation, but still keeping a central runtime. wazero has a "namespace" concept which can allow you to re-instantiate the same module multiple times with the same name (as is the case when we move WASI later in the lifecycle).

[daixiang0]

sorry if I'm a bit daft, but can you be precise where you want to update including both the repo and the directory names?

I mean https://github.com/dapr/samples, you can add a WASM sample.

[codefromthecrypt]

@daixiang0 cool for the sample. is there any thing else to do in this repo? I would like to have this land before updating https://github.com/dapr/samples so that the instructions can say the right function name.

[codefromthecrypt]

ok ready on my side, when this is merged I'll follow up on the sample no prob!

[daixiang0]

@codefromthecrypt codes look good overall, just some nits then we can make it land.

[codefromthecrypt]

@daixiang0 feedback sounds good. I generally make a sub-module readme instead of making a large one for the whole directory. I'll give it a go and if we need another revision no problem.

[daixiang0]

Also please fix CI.

[codefromthecrypt]

I'm unsubscribing as it is just merge bot stuff and fuzz from other broke things. If someone needs my help, please mention me!

[berndverst]

@codefromthecrypt I will merge this now. Can you please make any documentation updates and create the sample you were discussing previously in this issue.

[codefromthecrypt]

@berndverst thanks for owning getting this in, and of course thanks to @daixiang0 @Taction @ItalyPaleAle for review help also.

Good news is we already completed the docs based on this PR before and nothing drifted since then. https://docs.dapr.io/reference/components-reference/supported-middleware/middleware-wasm/

I'll follow-up with the sample once things merge, no prob!

[codefromthecrypt]

thanks for merging @artursouza! I opened this to bump deps and once in I'll do the sample mentioned in the desc dapr/dapr#5169