Epic Feature: Compile SQLPage site to WASM + dist folder

[olsonjeffery]

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

[lovasoa]

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.

[olsonjeffery]

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!

[lovasoa]

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.