Are there any approaches which implement server-side rendered SPAs with Rust? In that case Rust would render the HTML for the first load and server JSON APIs for changes in the SPA. Rendering the HTML is performance-intensive in my experience, using Rust could save up quite some computational resources.
Just serving static files from Rust is not that interesting. It definitely does not sound easier to me, since you are coupling deployment of both BE and FE with no resource optimization to get. Also, since built SPAs are essentially static files, their deployment could be just uploading these files to your CDN.
> Are there any approaches which implement server-side rendered SPAs with Rust? In that case Rust would render the HTML for the first load and server JSON APIs for changes in the SPA
Yes, frameworks like Dioxus (https://github.com/dioxuslabs/dioxus) implement next.js-like "fullstack" SPAs in Rust (the client-side code compiles to WASM).
> Rendering the HTML is performance-intensive in my experience, using Rust could save up quite some computational resources.
The server-side performance is indeed much better than JS alternatives (client-side performance is more or less the same).
I think there is Dioxus and Leptos if you want full-Rust solutions for SPAs. You're right that CDN is another thing that I forgot considering, too. Can you elaborate more on "coupling deployment of both BE and FE with no resource optimization"
Usually FE and BE are developed by different people or even teams. It's helpful to decouple release cycles of both components, or else a bug on one component could block deployment of a different component. It's important not to decouple deployments of two components when doing so would save up significant resources, but here decoupling could be achieved by deploying a separate nginx server with static files – this is incredibly cheap, as there is very little static overhead, and performance is comparable.
Dropping the static files on a CDN (eg. cloudflare pages) is pretty straightforward, cheap (and free), and doesn't impact your backend in terms of complexity or performance.
Your usecase can be useful for "local web applications" where you ship a binary and you get a local webui - but at that point, why not just build a Tauri app? (not electron as you would be shipping an extra browser instead of reusing the system one)
Thanks for the suggestion! I did not consider Tauri as it seems to be one machine only, while I'm developing my project to be a web app for multiple local machines.
Tauri will render a window with a web app inside on one machine. But that web app can communicate with a local backend that is either hosted by the same program, or some other program, locally or remotely.
Readit News
Just serving static files from Rust is not that interesting. It definitely does not sound easier to me, since you are coupling deployment of both BE and FE with no resource optimization to get. Also, since built SPAs are essentially static files, their deployment could be just uploading these files to your CDN.
Yes, frameworks like Dioxus (https://github.com/dioxuslabs/dioxus) implement next.js-like "fullstack" SPAs in Rust (the client-side code compiles to WASM).
> Rendering the HTML is performance-intensive in my experience, using Rust could save up quite some computational resources.
The server-side performance is indeed much better than JS alternatives (client-side performance is more or less the same).
The link to Leptos is https://github.com/leptos-rs/leptos for those who need it.
Your usecase can be useful for "local web applications" where you ship a binary and you get a local webui - but at that point, why not just build a Tauri app? (not electron as you would be shipping an extra browser instead of reusing the system one)
Deleted Comment
Deleted Comment
Dead Comment