This is WIP indeed.
The basic idea is that cargo leptos is responsible for calling cargo to
produce:
- The CSR target that will be loaded by a JS script in the browser,
- The SSR target that we want to compile to
wasm-wasip2component.
We will write some integration code to handle the HTTP Server
logic using wasi:http.
This is already done by Leptos for different HTTP framework, see here.
Of course, things are not so easy!
We need to be make sure most of the server logic can be compiled down to
wasm-wasip2 and implement fallback code to replace features that cannot be
compiled.
At this point, we should check if those can be compiled to our target:
- Routers,
- HTML Element Rendering,
- Server Functions (this is dependent on the actual code written by users ofc).
We need to hook into the server_fn crate to add adapters
to wasi:http.
If we can get to there, we can already call it a big win! 🎉
BUT! the user will likely want to use a custom world to leverage
the whole ecosystem. For example, maybe the user want to use
the new wasmcloud's Couchbase Integration to do some
NoSQL manipulation in the context of a Server Function. This means,
the leptos cargo plugin needs to allow the user to customise the world
and generate bindings accordingly.
Once we managed to get Leptos to output our backend as a component, we just have to integrate the produced artifact to the wasmCloud ecosystem.
We can imagine a CLI tool that will generate a wadm manifest for our backend and
optionally optimise it to work with wash dev allowing for a fast dev-loop
when building your full-stack ™️ app with wasmCloud 😎
As of Rust 1.82.0, IIUC, the two unstable features we may be interested in are:
wasi_ext: Some extensions tostd::fsandstd::net, but seems to be only nice-to-have.- the cargo feature
build-std, to rebuild the stdlib with optimisation of the WebAssembly target. While it's more of a nice-to-have for thessr, it's kind of important for production build of thecsras explained in Leptos Docs.
