Using or not using Arc for AppState in Axum

[warcayac]

Summary

I'm not sure whether to wrap AppState with Arc or not. All AI agents answer it is not necessary because AppState is internally wrapped with Arc but it is not explicitly mentioned in the official doc, even the official doc sometimes use Arc and other times not. Some similar occurs for adding Clone trait for AppState. This situation is presented in the examples available from Axum on Github, sometimes they use Arc and sometimes they don't.

This situation also extends to AppState fields or properties, do they need to be wrapped with Arc?

The reasonable doubt is that if Axum is used as a server, which is understood to serve concurrent requests by definition, shouldn't it by default treat any instance passed to "with_state" as something that will be shared and therefore wrapped with Arc?

axum version

0.8.1

[mladedav]

The state must just be clonable. When you extract the state, axum will clone it and pass it to your handler. It doesn't care if there is an Arc somewhere.

So you can use e.g. u32 as your state. However, when you mutate it, no other code will ever see it. Therefore, you almost always want to have something like Arc<AppState> or a cheaply clonable state with interior mutability.

[warcayac]

Thanks for your prompt response. If my state is a struct with multiple fields, some for read-only, and other for read-write, they need to be wrapped with something like this: Arc or Arc<RwLock>? or is it sufficient with wrapping my struct only?

[mladedav]

You can try it. But assuming you need mutable references to mutate the data, you'll probably need a lock.