You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 😬 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
The text was updated successfully, but these errors were encountered:
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.
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:
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
The text was updated successfully, but these errors were encountered: