seanaye/feat/js fetch

[seanaye]

What is this

This PR adds good-enough support for targeting the wasm32-unknown-unknown target on the server.

This opens up the door for deploying to edge platforms such as Cloudflare workers, Deno Deploy, Netlify Edge, etc.

Really anything that supports the standard fetch API and wasm

Still TODO (another PR)

figure out the integration with cargo leptos this is currently pretty rough

Usage

1. cd examples/hackernews_js_fetch
2. deno task build
3. deno task start

[seanaye]

It looks like the CI is trying to compile the new example and its failing because the build step is different

[gbj]

The changes made to the Axum integration here (removing get_leptos_pool and spawn_pinned) cause a panic at runtime when running the rendering functions or executing server functions.

thread 'tokio-runtime-worker' panicked at '`spawn_local` called from outside of a `task::LocalSet`', /Users/gjohnston/Documents/Projects/leptos-main/leptos/leptos_reactive/src/spawn.rs:85:13

[seanaye]

oh I thought that was being tested by CI and passing, my mistake. I'll add a cfg if block because creating the pool causes wasm to panic

[seanaye]

I am testing the server fns handling, it looks like the client and the server are generating different ids for the same function

fixed

[seanaye]

@gbj I think I might need some help getting the CI to play nice with the new example. Something with the matrix of different features is causing cargo clippy to fail

[gbj]

1. This is amazing — can confirm the example works.
2. I'm sure there's some additional cleanup that needs to be done (warnings etc.) to make the CI happy, can deal with that later.
3. The new reactive implementation uses tokio task-local variables to store the current reactive runtime per thread, to make sure there's no bleeding between requests. I'll probably need to do some testing to make sure that this works with server-side WASM, as using wasm_bindgen_futures::spawn_local opts out of the task-local runtime guarantees we're now able to provide with tokio task-local variables if there are multiple concurrent requests to the server.

[gbj]

Okay, sorry it's taken me a long time to get to this. It turns out that my point 3 above was wrong: I have run my standard test for this and it seems to work fine, without leakage across runtimes, and without any modifications. I suspect it has to do with the JS/WASM environment being single-threaded in any case: is Deno spinning up additional threads and running different JS runtimes in them for different requests?

The test, for future reference, and in case I screwed it up

1. Create a simple page with an element that synchronously uses {format!("{:?}", current_runtime())}
2. Add a server function that delays for one second, then returns the current runtime ID (formatted to a string), and render this in a Suspense
3. Spam the page with something like ab -n 512 -c 16 http://127.0.0.1:8000/
4. If the two RuntimeId values match, then we're not leaking between runtimes: each request is successfully running with a single RuntimeId

I'm honestly not sure what's going on with the CI. Digging into it a bit. It has to do with the combo wasm+SSR combo and feature flags, I'm sure.

[seanaye]

No, Deno will not spin up worker threads by default but in theory it would be possible. The rust futures do get run via the JS event loop though so it is 'non-blocking' in a sense, for IO-bound operations at least. I think that as long as we aren't leaking the runtime then leptos has fulfilled its end of the bargain, it would be up to the caller to do worker threads if desired. This would be separate WASM instances so if 1 runtime doesn't leak then N runtimes also wont leak.

Regardless, I think the main usecase for this PR is edge runtimes like Cloudflare Workers where threading is already abstracted away.

[9oelM]

@seanaye @gbj
hey there again. I have a question about why register_explicit is needed. Is it not supported for wasm32 servers yet?

[gbj]

@9oelM Correct, automatic registration isn't and can't be supported on WASM targets, and unless I'm mistaken that's documented in the server function docs.

[9oelM]

yeap got that thanks for the answer @gbj !!

[g2p]

@seanaye, the axum-js-fetch repo seems to be private, could you make it available?

[seanaye]

@seanaye, the axum-js-fetch repo seems to be private, could you make it available?

Yes of course, my mistake, I will do so later today

[seanaye]

@g2p https://github.com/seanaye/axum-js-fetch PRs are welcome