Limiting Factor: Difference between revisions

From Nasqueron Agora
No edit summary
 
(One intermediate revision by the same user not shown)
Line 10: Line 10:
For example, to use RequestBody:
For example, to use RequestBody:


<syntaxhighlight language="rust">
<syntaxhighlight lang="rust">
use limiting_factor_axum::api::guards::AxumRequestBody as RequestBody;
use limiting_factor_axum::api::guards::AxumRequestBody as RequestBody;


Line 41: Line 41:


See https://docs.rs/axum/0.8.4/axum/struct.Router.html
See https://docs.rs/axum/0.8.4/axum/struct.Router.html
== See also ==
;Limiting Factor
* [https://devcentral.nasqueron.org/project/view/119/ Project board / bug tracker]
* [https://devcentral.nasqueron.org/source/limiting-factor/ Source code]
;Nasqueron components using Limiting Factor
* [https://devcentral.nasqueron.org/source/alkane/ Alkane]
* [https://devcentral.nasqueron.org/source/docker-registry-api/ Nasqueron private Docker registry API]

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