This is, strictly speaking, a broader topic than just Rust, but I think everyone who's made a web application in Rust will know the answer, so I'm asking it here.
I know a Rust web server can render and serve HTML using crates such as maud or Askama, complemented, perhaps, by libraries like htmx, and of course there are all-in-one frameworks, such as Leptos and Dioxus, but if feasible, I'd like to write the front end in JavaScript and consume the Rust service as a REST API.
However, what I'm building would be best served as a multipage application. That means putting a JavaScript web server between the client and the Rust application to render the HTML. I'm not worried about performance or latency—Cloudflare's Workers are snappy and distributed all over the planet—but I don't know if this will mess with things like cookies. For example, I'm going to handle authentication on the Rust server. Will going through that API from a Cloudflare Worker at some times and from the client's browser at others work?
Furthermore, sometimes, the client will jump over the JS server and connect directly with the Rust server, for example to consume SSE events or a search API.
Do you think it's worth it to do that? Should I stick to SPAs? Do everything in Rust? This is the first web application I'm going to build, so I don't know how this is generally done.
The whole point of a multipage application is that you don't need separate JS to load, parse, and display the information, because the server does all that. That's good because it's less heavy on the user's/browser's side, but it's less elegant from an architectural point of view.
The point of a single-page application is that you clearly separate API from presentation, but in exchange, the client-side needs to be a fully-featured application with its own parsing and rendering logic, so it has to be maintained separately, and it'll usually be slower to load.
If you create all that logic and take on the burden of maintaining two separate codebases in parallel, then you shouldn't additionally complicate it with pretending to be an MPA.
This isn't true, either. What should this "web server" do, especially between the client and the backend? What would its benefit be? I really don't get this. If you do this sort of splitting, then the client should talk to the backend, and not to some middle man. What would the reason for adding yet another layer of complexity, when you already have the backend and the client?
When I talked about JavaScript, I largely had Astro in mind. It's a static site generator by default, but it allows for SSR by using an "adapter", which is a serverless function. It renders the non-static content. That's what I called the "JS server".
Regarding the "multipage app" part, it's mostly for SEO purposes, and because an SPA feels like overkill.
That's mostly a question concerning your hybrid framework and the configuration of your backend server, but I don't see why this should be a problem.
Based on your description you wouldn't put the web server between the Rust service and the client running inside the enduser's browser. You want to call the Rust service from both your client and your client's backend, so think of the Rust service as a third, completely decoupled entity that serves functionality to both your client and its backend.
Can't answer that for you as I've not done it yet, but it sure sounds like an enticing option for building frontends (for me who has struggled a lot with dynamically typed frontend languages that make it nearly impossible to get state management right while keeping your sanity). Dioxus, Leptos and yew all look applicable to your use case.