What are the advantages of using State vs Extensions?

[thomasmost]

Specifically, a route handler for me currently looks something like this:

pub async fn listed(Extension(pool): Extension<Pool>) -> axum::Json<Vec<Org>> {
  let dao = &mut OrgDao::new(&pool);
  let orgs = dao.get_listed();
  axum::Json(orgs)
}

vs

pub async fn listed(State(state): State<AppState>) -> axum::Json<Vec<Org>> {
  let pool = &state.pool;
  let dao = &mut OrgDao::new(pool);
  let orgs = dao.get_listed();
  axum::Json(orgs)
}

...but what are the advantages of using State for db pool management/why should I? I understand that state is shared between all routes but I think that's still true with this initialization, yes?

#[tokio::main]
async fn main() {
  ...
  let pool = init_pool();
  let app = Router::new()
    .route("/", get(service_info))
    .nest("/v0", v0_api)
    .layer(Extension(pool));
  ...
}

[davidpdrsn]

State is type safe, Extension is not. If you forget .layer(Extension(pool)); everything will still compile but fail at runtime. Not so with State.

[thomasmost]

Can you apply more than one state object to one router?

…

On Wed, Mar 8, 2023, 1:47 PM David Pedersen ***@***.***> wrote: State is type safe, Extension is not. If you forget .layer(Extension(pool)); everything will still compile but fail at runtime. Not so with State. — Reply to this email directly, view it on GitHub <#1830 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB44JJYWNCZ4QEYXVJTWFU3W3DH53ANCNFSM6AAAAAAVUDJRFA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[davidpdrsn]

With sub states sorta yes https://docs.rs/axum/0.6.10/axum/extract/struct.State.html#substates

[thomasmost]

I'm late following up on this but nice! This is exactly what I was looking for. Seems like a great pattern that affords the right flexibility/simplicity I'm looking for

[Geo-W]

Is it possible to use both? 😂

[davidpdrsn]

Middleware can't accesss state set by .with_state(). You have to pass it directly to something like from_fn_with_state. Hoping to fix that one day but dunno how to do it.

[oscar6echo]

Ok, this adds clarity.
I rephrase and summarize to make sure I get it - please correct me if wrong:

Each middleware is only aware of the state it receives in from_fn_with_state(). So each mw can use the same or different, presumably more specific, states. And theses are distinct from the one passed in with_state(). The latter is potentially available to handlers only.
Finally the way for a middleware to pass a state to handlers is via an Extension (not ideal as not type safe) or via a state if this one is passed both to from_fn_with_state() and with_state().

Is that a valid description ?

[davidpdrsn]

Each middleware is only aware of the state it receives in from_fn_with_state()

Yes they are distinct.

Finally the way for a middleware to pass a state to handlers is via an Extension

https://docs.rs/axum/latest/axum/middleware/index.html#passing-state-from-middleware-to-handlers

You cannot use state for this because state is global within a router. For request specific state use extensions.

[oscar6echo]

Ok clear thx 🙏

Middleware can't accesss state set by .with_state(). You have to pass it directly to something like from_fn_with_state. Hoping to fix that one day but dunno how to do it.

Btw I do not dislike this API: it allows fine grained control.
Various ways to pass states around are rather good I'd say, as long as it clearly documented.

[jasondemorrow]

@thomasmost Thanks for the for the well written question and follow-ups, I've learned a lot from this thread. You mentioned being interested in alternative implementations for your router above. I'm using axum-keycloak-auth for my auth layer, and its extension allows defining roles as an enum.

This simplifies the router definition BUT it has the disadvantage of parsing roles directly from the JWT payload. It could be that your middleware is fetching roles from a DB, which is a better practice. If that's the case, you might include in your app state a client or function for verifying roles against a given authenticated user:

pub enum Role { ... }

impl AppState {
  pub async fn verify_roles(roles: Vec<Role>, user: SessionUser) -> bool { ... }
}

The advantage of this approach is that it doesn't rely on layer ordering. The disadvantage is that it requires some boilerplate per handler. You could reduce this with something like:

pub async fn require_roles(roles: Vec<Role>, user: SessionUser) -> Result<(), MissingRolesError> { ... }

I'd prefer an approach like this, but I don't think one is clearly better than the other.