Dioxus fullstack app: desktop with embedded server

[azw413]

Feature Request or clarification

I have a fullstack Dioxus app which I want to distribute as a standalone Desktop i.e. self-contained with no reliance on a server but I also want to have a web version which will require a server to do all the backend processing.

If I run dx serve -platform desktop, it will start both the server and the desktop so can I just embed the server inside the desktop app with this sort of thing? :

#[cfg(feature = "desktop")]
#[tokio::main]
async fn main() {
    // Delete old log file
    let _ = remove_file(LOGFILE);

    // Initialise the logger
    fern::Dispatch::new()
        .format(|out, message, record| {
            out.finish(format_args!(
                "{} [{}] [{}] {}",
                chrono::Local::now().format("%Y-%m-%d %H:%M:%S"),
                record.level(),
                record.target(),
                message
            ))
        })
        .level(log::LevelFilter::Debug)
        .chain(fern::log_file(LOGFILE).unwrap())
        .apply()
        .expect("Can't initialise logging");

    info!("Shieldbench started");

    // Start the server
    let address = fullstack_address_or_localhost();
    let router = axum::Router::new()
        // You can add a dioxus application to the router with the `serve_dioxus_application` method
        // This will add a fallback route to the router that will serve your component and server functions
        .serve_dioxus_application(dioxus_server::ServeConfig::new(), Start);
    let router = router.into_make_service();
    let listener = tokio::net::TcpListener::bind(address).await.unwrap();

    tokio::spawn(async move {
        axum::serve(listener, router).await.unwrap();
    });

    dioxus::LaunchBuilder::desktop()
        .with_cfg(make_main_window_config())
        .launch(Start);
}

This doesn't work because the UI thread hangs but is there some way I can do this? Then the vanilla build for web works well.

[ealmloff]

Yes, it should be possible to do something like that. I'm not sure why your UI thread is hanging from that code, but tokio console can often be useful debugging such issues. You may need to create a new tokio runtime for the server on a separate thread instead of making main async because dioxus creates it own runtime inside of launch.

It might be easier to make your server functions normal async functions on desktop if you don't want to require a server. You can make the server attribute conditional with cfg_attr:

#[cfg_attr(not(feature = "desktop"), server("/route")]
async fn maybe_async_function_or_server_function() -> Result<()> {
    Ok(())
}

[Codys-Wright]

Do you know if its possible to embed the server into the desktop app? so it serves the WebUI just on the local network?

[azw413]

I tried your cfg_attr suggestion above and it works well. My issue now is that the code is just horrible and RustRover no longer accurately syntax checks it because there are so many gates to prevent the web app compiling all of the server. I tried following the guide: https://dioxuslabs.com/learn/0.7/essentials/fullstack/project_setup but this doesn't really alleviate that issue. I was hoping that I could cleanly separate the server from the web app so just the UI code exists in the wasm build. I know that Dioxus does some clever trickery in fullstack mode to generate the client side calls to the backend server function. I guess it also needs the data types being passed in each direction, but is there a way to completely isolate the server from the web client so it doesn't try and compile all of it and therefore require all of the gating? I have a sizeable app with 40+ modules and I have to try and make a case for using Dioxus to Rust beginners rather than using React, and I'm going to struggle unless I can get the code a lot cleaner.

[azw413]

I'm thinking of creating a server function facade module with all of the server endpoints in it that actually just call the real implementing functions in another module. The entire modules could be gated. It's a little ugly but might be better than the entire codebase littered with gates. Also, presumably the wasm file ends up with so much redundant code compiled in there too?