Limiting Factor: Difference between revisions
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
Limiting Factor is a library to help develop API in Rust, with Axum or Rocket 0.4 frameworks. | '''Limiting Factor''' is a library to help develop API in Rust, with Axum or Rocket 0.4 frameworks. | ||
== Development with Limiting Factor == | == Development with Limiting Factor == |
Revision as of 17:18, 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.