i'm seeking advice on re-organizing a Workspace project i'm working on that will be including plugins to be used by an HTTP Server, assuming the concept of using WASM plugins for a Rust server is ok.

the project is rooted at XXX, and has the following structure:

XXX
 +--- data (published as xxx-data)
 +--- server (bupblished as xxx-rs)
 +--- ...

the aim is to add support for runtime pluggable (WASI Preview 1) Components built as .wasm files. the source tree is expected to look like so:

XXX
 +--- interfaces
 |        +---- hashing (to be published as xxx-hashing) [1]
 +--- plugins
 |       +--- p1 (may be published.  if so, it'll be as xxx-hashing-p1) [2]
 |       +--- p2 (likewise --xxx-hashing-p2) [2]
 +--- data
 +--- server
 |      +--- plugins [3]
 |              +--- p1.wasm
 |              +--- p2.wasm
 +--- build-plugins.sh [4]

Notes:
[1] hashing contains the Rust trait, and a macro to generate a C-wrapper function to bridge the Rust and WASM divide --specifically to convert a WASM linear memory pointer and length into a Rust slice. it's built w/ crate-type of rlib. finally, this crate will be added as a dependency to the server, as well as to each plugin.

[2] concrete plugins have crate-type of cdylib, and are built w/ `--target wasm32-wasip1.

[3] a new folder w/in the server crate which houses the plugins' .wasm files. those will be bundled with the published xxx-rs crate.

[4] unless there's a way of mixing in the same workspace project building certain crates w/ one target, and others w/ different one(s), this is a bash script to invoke the

$ cargo b -p xxx -r --target wasm32-wasip1

commands for both plugins, ensure the plugins folder is present w/in the server folder, and copy the resulting .wasm files to that location.

a github proof-of-concept project illustrating this idea is here.

1 post - 1 participant

Read full topic