3 ms·

I'm using Axum now...its nice but still could use much more "batteries included" For example, I would like something like Go's Context for passing temporary pe

by newaccount2021 4y ago

I'm using Axum now...its nice but still could use much more "batteries included" For example, I would like something like Go's Context for passing temporary per-request data through middlewares...maybe this is possible with Axum but I'm not seeing a straightforward approach Extensions also seem to be kinda magical and not straightforward Immature ergonomics are still a hallmark of many Rust libs

jamincan 4y ago
Maybe tower-request-id is an example of how to implement something like that? https://github.com/imbolc/tower-request-id https://github.com/imbolc/tower-request-id
- newaccount2021 4y ago
  This is exactly what I am doing, but you shouldn't have to modify the request itself to pass temporary state
  - fasterthanlime 4y ago
    Eh, that's definitely a matter of taste. You definitely shouldn't have to pass an additional parameter everywhere you want context there's no absolutes here, just preferences.
  - masklinn 4y ago
    Why not? Given Rust's semantics it's really no different than how Go's Context seems to be used, just more efficient.
fasterthanlime 4y ago
Request extensions (a feature of the `http` crate, not specifically hyper/warp/axum) are "just" a typemap, which is "just" a HashMap where keys are TypeIDs rather than strings. It's slightly less footgunny than something like Go's Context, although I still dislike it because checking for the presence of something happens at runtime only, so if you're messing with middleware composition, it's still too easy to accidentally get it wrong.
masklinn 4y ago
> For example, I would like something like Go's Context for passing temporary per-request data through middlewares...maybe this is possible with Axum but I'm not seeing a straightforward approach That's probably more of a Tower(-http) thing. It's the bit which handles all the middleware, Tower is layered over that. > Extensions also seem to be kinda magical and not straightforward Yeah, the problem is that they come directly from the http crates so everything that's built on top assumes you know what it is. The reality is that Extensions are just a typemap, meaning it's a k:v where keys are types. So you can define your own state type, shove it in the Extension, and know that you'll be able to retrieve that and there will be no collision (because it's your state type). For a more complete introduction, see https://blog.adamchalmers.com/what-are-extensions/ https://blog.adamchalmers.com/what-are-extensions/ It's one of those topic which is so obvious afterwards that it's easy to forget it's completely opaque and obscure beforewards.

jamincan 4y ago

Maybe tower-request-id is an example of how to implement something like that? https://github.com/imbolc/tower-request-id https://github.com/imbolc/tower-request-id

newaccount2021 4y ago
This is exactly what I am doing, but you shouldn't have to modify the request itself to pass temporary state
- fasterthanlime 4y ago
  Eh, that's definitely a matter of taste. You definitely shouldn't have to pass an additional parameter everywhere you want context there's no absolutes here, just preferences.
- masklinn 4y ago
  Why not? Given Rust's semantics it's really no different than how Go's Context seems to be used, just more efficient.

fasterthanlime 4y ago

Request extensions (a feature of the `http` crate, not specifically hyper/warp/axum) are "just" a typemap, which is "just" a HashMap where keys are TypeIDs rather than strings. It's slightly less footgunny than something like Go's Context, although I still dislike it because checking for the presence of something happens at runtime only, so if you're messing with middleware composition, it's still too easy to accidentally get it wrong.

masklinn 4y ago

> For example, I would like something like Go's Context for passing temporary per-request data through middlewares...maybe this is possible with Axum but I'm not seeing a straightforward approach That's probably more of a Tower(-http) thing. It's the bit which handles all the middleware, Tower is layered over that. > Extensions also seem to be kinda magical and not straightforward Yeah, the problem is that they come directly from the http crates so everything that's built on top assumes you know what it is. The reality is that Extensions are just a typemap, meaning it's a k:v where keys are types. So you can define your own state type, shove it in the Extension, and know that you'll be able to retrieve that and there will be no collision (because it's your state type). For a more complete introduction, see https://blog.adamchalmers.com/what-are-extensions/ https://blog.adamchalmers.com/what-are-extensions/ It's one of those topic which is so obvious afterwards that it's easy to forget it's completely opaque and obscure beforewards.