Skip to content
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

Epic Feature: Compile SQLPage site to WASM + dist folder #125

Open
olsonjeffery opened this issue Nov 6, 2023 · 3 comments
Open

Epic Feature: Compile SQLPage site to WASM + dist folder #125

olsonjeffery opened this issue Nov 6, 2023 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@olsonjeffery
Copy link

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

@lovasoa lovasoa added the enhancement New feature or request label Nov 6, 2023
@lovasoa
Copy link
Collaborator

lovasoa commented Nov 6, 2023

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 actix/actix-web#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
Copy link
Author

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
Copy link
Collaborator

lovasoa commented Nov 7, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants