how about adding reload feature for axum?

[zishon]

I have read all the crate document and post here
I don't find feature such as nginx have: nginx -s reload
I think this feature is useful, how about adding reload feature for axum in future version?

[davidpdrsn]

What does nginx -s reload do?

[zishon]

It starts new workers, and old workers continue process connections which already accepted.
It does not stop the service while loading new configs.

[jplatte]

Hot reloading when the code changes can be achieved using listenfd + systemfd + cargo-watch.

Maybe we should add an example for that. @davidpdrsn wdyt?

[zishon]

I don't think this is code relevant mechanisms.
Set up a standardized configuration scheme for axum may be a solution.

[jplatte]

No, we are not going to add configuration to axum. The way you read your config file now isn't required for me to make an example of how to reload, but it will make it easier and I'm helping you voluntarily afterall.

[zishon]

use std::fmt::format;

use axum::{Extension, Router};
use axum::extract::State;
use axum::response::{IntoResponse, Response};
use axum::routing::{get, post};
use toml::Value;

#[derive(Debug, Clone)]
struct AppConfig {
    app_id: String,
    app_secret: String,
}

#[derive(Debug, Clone)]
struct User {
    name: String,
}

impl IntoResponse for User {
    fn into_response(self) -> Response {
        format!("User Name: {}", self.name).into_response()
    }
}

async fn hello(State(app_config): State<AppConfig>) -> User {
    //get user information from user service by using app_id and sign
    println!("{}", app_config.app_id);
    println!("{}", app_config.app_secret);
    User {
        name: "Demo".to_owned(),
    }
}

#[tokio::main]
async fn main() {
    let raw_config = tokio::fs::read_to_string("config.toml")
        .await
        .expect("Failed to read config.toml");
    let parsed_config: Value = toml::from_str(&raw_config)
        .expect("Failed to parse config.toml");

    let app_id = parsed_config.get("app_id").expect("Failed to read App ID");
    let app_secret = parsed_config.get("app_secret").expect("Failed to read App Secret");

    let app_config = AppConfig {
        app_id: app_id.to_string(),
        app_secret: app_secret.to_string(),
    };

    let app = Router::new()
        .route("/hello", get(hello))
        .with_state(app_config);

    // run it with hyper on localhost:3000
    axum::Server::bind(&"0.0.0.0:3000".parse().unwrap())
        .serve(app.into_make_service())
        .await
        .unwrap();
}

[jplatte]

Alright, so it's just a small struct that is cloned everywhere and parsed using the toml crate. In that case, I would recommend making your state type

use std::sync::RwLock;

struct AppState {
    // Could also use the arc_swap crate for Arc<ArcSwap<Arc<AppConfig>>>
    config: Arc<RwLock<AppConfigInner>>,
}

// With the derived Deserialize impl, you can use
// toml::from_str::<AppConfigInner>(&raw_config)
// directly, instead of going through toml::Value
#[derive(Deserialize)]
struct AppConfig {
    app_id: String,
    app_secret: String,
}

// To allow extracting State<AppConfig> but supplying `.with_state(<AppState instance>)`
impl FromRef<AppState> for AppConfig {
    fn from_ref(state: &AppState) -> Self {
        state.config.read().unwrap().clone()
    }
}

then you can share a clone of the Arc<RwLock<AppConfigInner>> with whatever update mechanism you want for the config.

For unix-like systems, I would recommend you hook up the SIGHUP signal, which is a (semi-?)standard way of signalling a process that it should reload its configuration. You could spawn a background tokio task with tokio::spawn that checks for Signal::Hup using the async-signal crate, and once it has received that signal, it reloads the config file and writes it to the shared Arc<RwLock<AppConfig>> using *shared_config.write().unwrap() = new_config.
To send this signal, you can use pkill -SIGHUP <name of the executable> or kill -SIGHUP <process ID>.

Feel free to ask any follow-up questions if the above isn't totally clear.

[zishon]

So appreciated for your help.

[davidpdrsn]

Maybe we should add an example for that. @davidpdrsn wdyt?

Yeah that sounds like a good idea! I've never set something like that up myself.