Static assets for deployment in GitHub Pages

[storopoli]

Right now (as far as I understood) we can only have the website available by running with cargo run --release.

I would love to have an index.html with an assets folder that I can deliver to the static GitHub Pages.

[edezhic]

I've been thinking about supporting static scenario and I'm interested in it, but I haven't found a good way to implement it yet. Easiest solution could have been to make requests to the server on the registered routes and collect responses into files, but axum, library that prest uses for routing, doesn't expose these routes anywhere afaik.

[jonititan]

Those examples that use pwa would seem to be suitable for this type of deployment? Since if they are running in a service worker in wasm they can be started and loaded from index.html would be the first thing served by github pages? Basically the same way Jupyterlite is loaded.

From reading the internals I thought that was one of the end aims of the project? Not just pwa but also permitting advanced rust internals and interactivity in an otherwise statically served site.

Edited to add:
That's what the example that inspired you does as well. Rust wasm service worker

[edezhic]

@jonititan That's a fair point that I haven't thought about much. While enabling rust power on the client side is one of the goals, static deployments aren't that important to me, at least right now.

One of the reasons is that wasm isn't well supported in browsers and service workers are still buggy even in pure js, so going all-in in this direction is premature. I hope that it will change in the near future but realistically it will likely take at least a year to get stable SWs, browser api access directly from wasm and other features required for nice DX with rust on the client side.

Another reason is that I'm focused more on the server side for now. I'm hoping to achieve the deployment simplicity of a managed wordpress service but with prest on any linux vps. 5$/month doesn't seem like a big deal if you won't have to worry about devops things and could serve thousands of users across any number of apps.

Overall I think getting to almost-zero-setup server+DB just makes more sense right now. While I believe rust has a lot of potential on the client side, and I think of prest as one of the projects that shows it, unfortunately this ecosystem isn't ripe yet to compete with JS's DX, so I'd rather focus on features that can already be more convenient than existing tooling

[jonititan]

That's completely understandable. Thanks for explaining your reasoning.