How to run in WasmCloud?

[tqq1994516]

I have looked at the examples of WasmCloud. They used the wasmcloud-component and wit-bindgen crate instead of wasi. I'm not sure if it will have any impact.

[tqq1994516]

I have read the introduction of the wasi crate. It also generates wasi:cli/command and wasi:http/proxy through wit-bindgen. However, for the project to adapt to the wasmcloud environment, using wasmcloud.toml and the wash client tool, and directly using wit-bindgen to customize WIT dependencies in the crate should be more flexible.

This crate contains bindings for WASI APIs for the worlds:
wasi:cli/command
wasi:http/proxy
This crate is procedurally generated from WIT files using wit-bindgen.

[raskyld]

Hello!

The component you obtain from using the template there: https://github.com/leptos-rs/start-wasi is using native WASI interfaces so you shouldn't have any trouble running it in a wasmCloud environment.

Sadly, the only way I have found to let users pass the WASI types in the Handler is by using a common crate that could be shared between the user and this library (i.e. the wasi crate).

I am not aware of a way to ease the process, I know you can use a custom WIT world and use the "types" from another crate but I am not experienced enough with that.

cc @brooksmtownsend, do you have any insights? 🙏

[tqq1994516]

The component you obtain from using the template there: https://github.com/leptos-rs/start-wasi is using native WASI interfaces so you shouldn't have any trouble running it in a wasmCloud environment.

I've tried and the backend works fine. However, it seems that the existing approach doesn't allow the front-end static resources to be used directly. After reading the WasmCloud documentation, it appears that in the WasmCloud environment, a filesystem is required and it also seems necessary to use WASI-Virt to embed a specific Wasm for mounting static resources so that they can be used normally.

[tqq1994516]

Sadly, the only way I have found to let users pass the WASI types in the Handler is by using a common crate that could be shared between the user and this library (i.e. the wasi crate).

I am not aware of a way to ease the process, I know you can use a custom WIT world and use the "types" from another crate but I am not experienced enough with that.

The wasi crate contains limited WebAssembly Interface Types (wit) dependencies. I think that if one wants to use the WasmCloud ecosystem flexibly, when initializing templates with command-line tools, it might be necessary to either on demand or by default include some wit deps as a local WASI crate that can be depended on by leptos_wasi. Later, if needed, one can also modify the world on their own. Moreover, in cases where embedding is required as I mentioned above, I think it will be relatively easy to handle as well.

[raskyld]

I think we should have another crate specifically for wasmCloud anyway.

This is what folks with Spin do. They integrate leptos_wasi in their spin integration crate to have a DX really tailored for Spin users.

[benwis]

Isn't that what this is? https://github.com/raskyld/leptos-wasmcloud

…

On Wed, Dec 11, 2024, at 4:08 AM, Enzo Nocera wrote: I think we should have another crate specifically for wasmCloud anyway. This is what folks with Spin do. They integrate `leptos_wasi` in their `spin` integration crate to have a DX really tailored for Spin users. — Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVBTCP2SFEU5CVUICBSH7D2FATKPAVCNFSM6AAAAABS3IBDC6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZVHAYTINBXGE>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[raskyld]

Nope, actually this repo has wasmCloud in its name because I initially intended to work on wasmCloud integration but I ended-up focusing on a pure-WASI first to have a reusable piece for the broader eco-system!