lovasoa
Epic Feature: Compile SQLPage site to WASM + dist folder
I'm a new SQLPage user, who would love to "ship" the SQLPage experience into a self-hosted browser context. This could be useful for deploying into environments that only accept static assets (ie Github pages).
At a really high level:
- The SQLPage bin is extended to "compile" the current directory (or a provided path), which is expected to be a "valid SQLPage site"
- The SQLPage engine/bin itself would be shipping as a wasm blob
- SQL scripts are bundled as assets, all of the tabler/etc JS stuff is minified and shipped in dist
- By convention include/bundle stuff in /content, /js, etc?
- By configuration we can require the site to be sqlite in-mem (I actually encountered a Jupyter wasm demo that includes in-mem sqlite and it's pretty slick; part of this inspiration for this issue)
- Migration scripts run on start, build out the site on each page load (probably the most :grimacing: part of the whole thing, and SQLPage isn't really "built" for SPA contexts, so not sure there's much getting around this one)
- Lots of stuff to figure out here in terms of what javascript footholds are needed for SQLPage in wasm (yew, wasm-pack, etc are good places to look for this)
This is a pretty huge bit of work, and I hope that my grasp of the SQLPage architecture is sufficient to articulate this idea and I'm not speaking gibberish. I am interested in Rust + WASM, so this is something I will probably look at as I learn more about the architecture.
Please let me know if this is something that the project is interested in!
Cheers, Jeff
Hello and welcome to SQLPage ! What you say makes a lot of sense, and I would be very happy to see it work.
But as you say, this represents a significant amount of work. A good starting point would be https://github.com/actix/actix-web/issues/340
If you could get actix-web to compile to wasm, that would be very useful to a lot of people, even outside of SQLPage.
Thank you for linking the actix-web issue. I'm glad I'm not the first to have thought about this. It seems like a pretty deal on their end.
Would it be possible/worth it to refactor the actix-web portion behind a feature flag/crate, and introduce another for wasm/browser feature and then handle them as separate concerns?
Right now, actix-web is doing (at least) two things: 1 - providing platform application structure (entry points for requests into the SQLPage system) 2 - handle HTTP transport plumb
#2 doesn't exist in the browser, #1 is just incidental.
I'm just thinking about loud. Please share your thoughts!
Yes, actix web provides all the base types for representing requests, headers, cookies, etc... You could factor it out, but that also would be a lot of work, and the result would be less useful than getting actix web to compile to wasm.