-
-
Notifications
You must be signed in to change notification settings - Fork 657
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Makes the wasm32-wasip1/2
target a first-class citizen for Leptos's Server-Side
#3063
Conversation
@raskyld This looks interesting. Adding generics to server fns to make them more versatile could be handy. I need to spend some time looking at what you did there. I think you want to take a look at leptos-spin and leptos-spin-macro. We're keeping most new integrations out of the main crates to reduce the time needed to release a new feature, but I'm happy to create a leptos-wasi and leptos-wasi-macro in the leptos org if you'd like. As far as the Leptos specific changes, it seems like you've broken some of the examples, so you'll want to review those |
Hello @benwis thanks a lot for your answer. Let me check that! I should move the whole I will likely need an example / starter crate as well, ported from https://github.com/raskyld/leptos-wasmcloud |
bed615d
to
88f5e0d
Compare
any_spawner/src/lib.rs
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gbj since you are the author of this crate, could you guide me on how I implement a single-threaded implementation for running the server side in Wasm?
The current implementation works but I don't really like it.
I think I have no choice to expose a handle to LocalPool::run()
since, unlike tokio and glib, there is no "ambiant" executor and the caller is responsible for starting the pool.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might want to look at the #3091, it looks like they're trying to add futures-executor. Is the wasip1 build that we do for Spin already do the single threaded executor/ Or is this unique to wasmcloud
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dicej pointed me out the executor used by spin is part of the spin SDK crate, so I should definitely go and have a look!
I will also check the linked PR since that would allow me to implement that out of tree aswell! Thanks!
Potentially, waiting for the release of the next Rust release that should come with a promotion of the |
wasm32-wasip1
target a first-class citizen for Leptos's Server-Sidewasm32-wasip1/2
target a first-class citizen for Leptos's Server-Side
Yeah, I'd make this a whole seperate crate. You could choose to wrap it up in a single integration crate like leptos-wasmcloud, or if you want to support other wasm function implementations you can do leptos-wasi |
We definitely should go for |
CI errors may be my bad: I wanted to make my clippy more annoying since I count on that to grow my Rust knowledge a bit but It looks like it also applied to tests 🤔 |
Chiming in from the wasmCloud side, very in support of a Edit: I left a suggestion and a future improvement, hope that's alright! |
server_fn_macro/Cargo.toml
Outdated
@@ -21,6 +21,8 @@ nightly = [] | |||
ssr = [] | |||
actix = [] | |||
axum = [] | |||
wasi = ["generic"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once wasm32-wasip2
is a stable target in Rust (coming in 1.82 afaik) the use of feature flags could be simplified, using the target directive instead https://doc.rust-lang.org/nightly/rustc/platform-support/wasm32-wasip2.html#conditionally-compiling-code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True! I initially went for the feature to kind of follow the other integrations but since we have a target I may just use that!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
edit: This is live now in Rust 1.82!
#3091 has been merged, I will rework the PR on that point, my new approach will be to bundle a custom WASI async runtime exposed to Leptos as a This may be reconsidered once we add first-party support to |
b0d7a37
to
6f847f8
Compare
Implemented an async runtime which supports waiting for Tested a dumb "sleep 3s" c.f. raskyld/leptos-wasmcloud@a683304#diff-3f1994a48e642525e7a77d762690a04f386ec355bef4a97826ff0b4f54ef2239R61 This makes |
What is missing at this point is:
|
Yeah, wasmtime doesn't support |
wasm32-wasip1/2
target a first-class citizen for Leptos's Server-Sidewasm32-wasip1/2
target a first-class citizen for Leptos's Server-Side
Alright, I think the PR is ready-ish for a first review, but considering there is a lot of changes, we should likely start the migration to a dedicated repository. As I test and play with this crate, I will make it incrementally more production ready (add test suites etc..). |
@raskyld I've created the leptos_wasi repo under the leptos org and added you as a maintainer. Lmk if that doesn't work and we can get started! |
Yay! Thanks 🙏 I will take the integration crate to a PR on this new repo after work :D 🎉 |
FYI, migration is done! I will present the PRs at the next wasmCloud Community Meeting (next Wednesday). |
I will rebase and run |
Signed-off-by: Enzo "raskyld" Nocera <[email protected]>
This commit adds `From` implementations for the `Req` and `Res` types using abstraction that are deemed "platform-agnostic". Indeed, both the `http` and `bytes` crates contains types that allows us to represent HTTP Request and Response, while being capable to target unconventional platforms (they even have `no-std` support). This allows the server_fn functions to target new platforms, for example, the `wasm32-wasip*` targets. Signed-off-by: Enzo "raskyld" Nocera <[email protected]>
Signed-off-by: Enzo "raskyld" Nocera <[email protected]>
…rver-side Signed-off-by: Enzo "raskyld" Nocera <[email protected]>
Signed-off-by: Enzo "raskyld" Nocera <[email protected]>
Signed-off-by: Enzo "raskyld" Nocera <[email protected]>
I ran clippy in really annoying mode since I am still learning Rust and I want to write clean idiomatic code. I took suggestions that I thought made sense, if any maintainers think those are *too much*, I can relax those changes: * Use `core` instead of `std` to ease migration to `no_std` (https://rust-lang.github.io/rust-clippy/master/index.html#/std_instead_of_core) * Add documentation on exported types and statics * Bring some types in, with `use` * Add `#[non_exhaustive]` on types we are not sure we won't extend (https://rust-lang.github.io/rust-clippy/master/index.html#exhaustive_enums) * Add `#[inline]` to help the compiler when doing cross-crate compilation and Link-Time optimization is not enabled. (https://rust-lang.github.io/rust-clippy/master/index.html#/missing_inline_in_public_items) * Use generic types instead of anonymous `impl` params so callers can use the `::<>` turbofish syntax (https://rust-lang.github.io/rust-clippy/master/index.html#/impl_trait_in_params) Signed-off-by: Enzo "raskyld" Nocera <[email protected]>
Signed-off-by: Enzo "raskyld" Nocera <[email protected]>
Signed-off-by: Enzo "raskyld" Nocera <[email protected]>
Signed-off-by: Enzo "raskyld" Nocera <[email protected]>
Remove clippy crate rules since it seems to make tests fails in tests. Signed-off-by: Enzo "raskyld" Nocera <[email protected]>
Signed-off-by: Enzo "raskyld" Nocera <[email protected]>
Signed-off-by: Enzo "raskyld" Nocera <[email protected]>
Signed-off-by: Enzo "raskyld" Nocera <[email protected]>
This commit adds a single-thread "local" custom executor, which is useful for environments like `wasm32` targets. Signed-off-by: Enzo "raskyld" Nocera <[email protected]>
This commit adds a single-threaded async runtime for `wasm32-wasip*` targets. Signed-off-by: Enzo "raskyld" Nocera <[email protected]>
This commit adds error types for the users to implement better error handling. Signed-off-by: Enzo "raskyld" Nocera <[email protected]>
Signed-off-by: Enzo "raskyld" Nocera <[email protected]>
Signed-off-by: Enzo "raskyld" Nocera <[email protected]>
Signed-off-by: Enzo "raskyld" Nocera <[email protected]>
bdc5e3c
to
c909802
Compare
Hopefully that should be it, I ran |
Meh, I must be using cargo make in a wrong way or my rebase messed it, I will double check later today 😓 |
Here is the little demo I made at wasmCloud Community Call, excuse my terrible french accent that went wild 🤣 |
Signed-off-by: Enzo "raskyld" Nocera <[email protected]>
Oh god I've just got it! |
Signed-off-by: Enzo "raskyld" Nocera <[email protected]>
Fixed the clippy error for |
Ah! Now I have the backtrace! |
Signed-off-by: Enzo "raskyld" Nocera <[email protected]>
@raskyld Bet that feels good! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks for all the hard work here!
Abstract
This PR is a first step towards making Leptos capable of targeting
wasm32-wasip1
(andwasm32-wasip2
when it is released) for the server-side.ATM, I managed to
wasmtime serve
the component produced when runningcargo-leptos build
on this codebase.I started working on this PR with the end-goal of making it easy to host the server-side on a wasmCloud lattice.
While wasmCloud is a CNCF Sandbox project, I would understand if you don't want to have anything related to this project in-tree. For this reason, this PR is focused on running on purely standard WASI. The produced component have 0 dependencies on any vendor. Which is why I think this PR could be merged in-tree.
For my following work, specifically focused on wasmCloud, I would do that out-of-tree. (Expect if maintainers have interest supporting wasmCloud as a first-class citizen aswell! 🚀)
Features
generic
feature toserver_fn
to make it portable across a wide range of platform.any_spawner
's custom executor feature (implemented by @stefnotch! 🎉) allowing the futures to run in the context of a WebAssembly runtime.wasm32
targets.leptos_wasi
allowing Leptos users targeting thewasm32-wasip1
platform to make their app deployable on any WASI runtime (for now, I only testedwasmtime
)SsrMode
are compatiblewasi:filesystem
link providedby the
--dir target/site/pkg
flag ofwasmtime serve
.Limitations
SsrMode::Static
is not supported, I don't think it should be too hard to do, but for now it's not on my roadmap.Road-map
any_spawner
, I really don't like my current changes.wasi
crate for the bindings.leptos-wasi
in the organisation