Limiting Factor: Difference between revisions
No edit summary |
|||
Line 10: | Line 10: | ||
For example, to use RequestBody: | For example, to use RequestBody: | ||
<syntaxhighlight | <syntaxhighlight lang="rust"> | ||
use limiting_factor_axum::api::guards::AxumRequestBody as RequestBody; | use limiting_factor_axum::api::guards::AxumRequestBody as RequestBody; | ||
Latest revision as of 17:26, 24 September 2025
Limiting Factor is a library to help develop API in Rust, with Axum or Rocket 0.4 frameworks.
Development with Limiting Factor
Axum
Gotchas during development of With axum and limiting-factor-axum:
Order of extractors
axum::extract order of extractors - the request is consumed by an extractor, so it must be the LAST parameter of any request handler method.
For example, to use RequestBody:
use limiting_factor_axum::api::guards::AxumRequestBody as RequestBody;
// Valid code
pub async fn init(
Path(site_name): Path<String>,
State(config): State<AlkaneConfig>,
context: RequestBody,
) -> Json<T> {
...
}
// Will trigger a compile error with axum even if that order is fine on Rocket
pub async fn init(
Path(site_name): Path<String>,
context: RequestBody,
State(config): State<AlkaneConfig>,
) -> Json<T> {
...
}
Development of Limiting Factor crates
Axum
Router
The Router type is documented to be Router<S>
where S is the type of the state. This S has a very axum-specific special meaning, it means "the router needs a state of type S, and that state is still missing".
When we missed that information, it was tempting to use Router<S>
for App structure. As the final router passed to axum::serve was Router<S>
instead of Router<()>
, compiler complained about cumbersome and complex missing traits for S.
See https://docs.rs/axum/0.8.4/axum/struct.Router.html
See also
- Limiting Factor
- Nasqueron components using Limiting Factor