`create_resource` panics when server is compiled to wasm32-wasi about leptos HOT 8 CLOSED

@diversable Hmm, interesting. A Spin handler can't declare a tokio::main (it's a wasi-http incoming-handler) but presumably we could create a Tokio single-threaded runtime by hand at the start of the request. I'm not sure whether that would add overhead or how it would interact with host async features, but definitely another angle to investigate. Thanks!

from leptos.

I re-read the Hydration Bugs part of the book and now wonder if the correct fix is to enclose the create_resource in a create_effect. But I am not sure what the scope of that create_effect should be, because the counter resource is used later on the page.

from leptos.

Excellent, thanks for raising this point! Initially wasm-bindgen-futures was only used for the browser, then a PR was made to use it for all wasm targets so that wasm32-unknown-unknown running in a JS environment on the server(less?) (Deno Deploy, Cloudflare Workers, etc.) would work. But obviously this then doesn't work for wasm32-wasi, which I definitely want to move toward full support for.

But I have a question: Is this really the recommended way to do async in Spin?

        if #[cfg(all(target_arch = "wasm32", target_os = "wasi"))] {
            futures::executor::block_on(fut)
        }
        else if #[cfg(target_arch = "wasm32")] {
        // ... rest as before ...

I don't know enough about the architecture: Does Spin handle separate requests as separate threads? i.e., is it safe to block on async like this? Or is there some other async support?

from leptos.

@gbj Spin handles separate requests as separate WebAssembly instances: that is, each request instantiates a request handler but that handler runs entirely separately from any other handlers. The handler is, I believe, single-threaded.

That said, Spin handlers do have a limited level of async/await. For example, if a handler makes an outbound HTTP call, it gets a future back, and can await that. But it isn't general-purpose async/await. We can't use tokio or other concurrent runtimes. It is, as far as I know, strictly bound to implementations of WASI pseudo-futures in the Spin host.

That said, I don't know if it's possible to have a long-running WASI host - one where a single instance handles all requests within the same module. I don't think WASI threading would enable that yet, but it could be a future risk with my fix.

I'll follow up with the Spin WASI experts to see what they think.

from leptos.

In that case your solution sounds correct and I'd accept it as a PR in a heartbeat.

from leptos.

Thanks for the encouragement @gbj. I ran this past my colleague @dicej who is more knowledgeable about WASI and Spin internals than me, and he flagged a concern that the implementation of futures::executor::block_on would block forever if the future was pending when first polled. There's no great solution here, but Joel's advice was that we should poll the future in the same way as futures::executor::block_on, but if the future was not ready, we should panic rather than looping and polling again.

I've tested this and it Works On My Machine for the counter_isomorphic sample. I'll send a PR and can cover off some of the considerations there.

Longer term there is some stuff in the Spin SDK that we might be able to extract and generalise into a more robust poll_list-based executor for WASI. I'm not sure what the effort and risks there are though...!

from leptos.

... We can't use tokio or other concurrent runtimes. ....

quick note about tokio, since I've spent some time trying to get Axum & Tokio to work properly with Leptos in a wasm / wasi context: Tokio does actually have a 'single-threaded' mode if you add the right 'flavor' to your tokio main fn.

ie.

#[tokio::main(flavor = "current_thread")]
async fn main() {
...
}

& in your cargo.toml, tokio supports the following features:

tokio = { version = "1.25.0", features = [
    "rt",
    "sync",
    "macros",
    "io-util",
], optional = true }

In a wasm32-wasi context, you can use the "time" feature in tokio too.

See here for more info: https://docs.rs/tokio/latest/tokio/#wasm-support

I still don't have it sorted out yet, but I'm working on putting together a wasm/wasi template for Leptos+Axum - great to see your work here as well!

from leptos.

FYI:
there seems to be an issue with running the full Leptos+Axum stack in a wasi context - it looks like hyper hasn't accepted the pull request that adds wasi support (yet)..

here it is for reference: hyperium/hyper#2900

tokio does have wasi support, though, and apparently there aren't any blockers from axum itself.

I'm not familiar enough with Spin to know if it would even support running hyper .. i'm still learning the finer details of wasi rt's

there is this example with hyper client wasi support, though: https://github.com/WasmEdge/wasmedge_hyper_demo

from leptos.