Mutable State (Rust & Rocket newbie)

[DuredhelFinceleb]

How to get mutable application State?
I'm using rocket.manage() and I was stuck when trying to update the state.
I read on Google that I had to wrap my data into an Arc then Mutex (at my current Rust level, I understand what these are but my use of them is cut & paste)
So I ended up doing this (and somehow it works!)

struct AppState {
    users: HashMap<String, Instant>,
    valid_auth_duration: u64,
}

type AppStatePointer = Arc<Mutex<AppState>>;

impl AppState {
    fn new(valid_auth_duration: u64) -> AppStatePointer {
        let new_app_state = AppState {
            users: HashMap::new(),
            valid_auth_duration,
        };
        Arc::new(Mutex::new(new_app_state))
    }
}

#[get("/")]
fn index(auth: BasicAuth, app_state: &State<AppStatePointer>) -> String {
    let mut app_state = app_state.lock().unwrap();
    let valid_auth_duration = app_state.valid_auth_duration;
    let users = &mut app_state.users;
    match users.get(&auth.username) {
        None => {
            users.insert(auth.username.clone(), Instant::now());
            ...
        },
        Some(instant) => {
            ...
        }
    }
}

#[rocket::launch]
fn rocket() -> _ {
	rocket::build().manage(AppState::new(30)).mount("/", routes![index])
}

My question is: is this the Right Way to do this?
Is there a best practice for this?
Or bettert yet, is there something built in for handling mutable state?

[somehowchris]

From my point of view, there’s not much else to do than using Mutexs in Arcs, if you're into Async things you might wanna have a look into locks and mutexes with Tokio or async_lock to not block a thread just for waiting.

Mind if I ask the question. Why would you need to edit a state after liftoff? I see that your example uses users as a storage which I guess would be an abstraction of a db but where would you use mutatable state in a (preferably statless) app?

[DuredhelFinceleb]

Thanks for your answer: duly noted about Arc + Mutex being the way to go

I've had a look into Tokio Mutex: it works great! And I prefer having an await that cannot fail than an unwrap I'm still not sure how to repalce with a match (I mean my understanding is that I should not leave unwraps in prod code since they can panic) as it's not clear to me what I should do with the Err arm of the match.
However, the Tokio doc says its Mutex version should be used only when standard Mutexes are not an option and suggests that best practice is to add functions to the struct to encapsulate the stadard Mutex lock & the manipulation of the data, so I did that.

As for your question
The hashmap really is the store => I'm doing some in-memory caching & don't care if it's wiped out when the process dies. This is a very simple app so I did not want to go with things like Redis, really a simple hashmap is enough
However, I did not have a clue (and I still don't) on how I'm supposed to have some global vars accessible for all functions
I've read things about static variables and OneCell, etc. and to me it was complex enough to mean "newbies should not fiddle with global vars anyway"
And then I've found out about rocket::manage => it's entirely possible that I'm not using it for what it's intented to do

[somehowchris]

You should only use the mentioned constant (static) variables if they are read only. Const variables are evaluated at compile time and aren‘t meant for traditional global states like you would use in python, java or javascript.

Going Async means that usual mutexes aren‘t an alternative. Rocket manage is the way to go if you need a global state in the lifecycle of rocket. It‘s not constant and therefore mutatable and it‘s bound within the context of the functions of your endpoint. Rocket uses a functional approach to structure and not an object oriented one (like expressjs (JS) or fastapi (Python))

[DuredhelFinceleb]

Thanks a lot for your answer, it clarifies a lot of things for me!

[somehowchris]

If your question has been answered, could you please mark this thread as answered?