Wrapper for handler to handle from/to Json conversion

[kirillsalykin]

Summary

Please help,

I'd like to have a handler wrapper so it can handle Json conversion for me:

for instance I this sign_up handler:

#[derive(Deserialize)]
struct SignUpRequest {
    email: String,
    password: String,
}

#[derive(Serialize)]
struct SignUpResponse {
    user_id: String,
}

async fn sign_up(request: SignUpRequest) -> Result<SignUpResponse, String> {
    let user_id = "some_generated_user_id".to_string();
    Ok(SignUpResponse { user_id })
}

I am looking for a function wrap which I expect to be used this way:

        let router = Router::new()
            .route("/sign-up", post(wrap(sign_up)));

        let listener = tokio::net::TcpListener::bind(addr)
            .await
            .unwrap();
        let addr = listener.local_addr().unwrap();
        println!("listening on {}", addr);
        axum::serve(listener, router);

and it should perform JSON extraction, run the wrapped async function, and then produce the corresponding Response based on the result.

I'm having a hard time producing such code.
Any help would be much appreciated. Thanks!

axum version

0.7.7

[mladedav]

Is Json something that would solve your problem? Or do you really need your signature to be exactly as you wrote and you do need a wrapper around that?

[kirillsalykin]

Json definelty solves the problem, but I'd like to keep Json (both extraction from request and response serializion) in http level.

Would be nice if wrap fn can do this:

• extract `Json< SignUpRequest> and pass it further to wrapped fn
• based on result from the wrapped fn - if Ok - return (Ok, Json(result)), if Err - provide corresponding error code and details

I can imagine I am not the first who thought about this, but cant find much solutions.

Thanks

[kirillsalykin]

It also makes me think how to handle state extractors, like pgpool...
of course I can write handler which extracts things and passes it further and then handles the result, but this is basically boilerplate.
Would appreciate if someone can share ideas/solutions on this

[mladedav]

I'm not sure what do you mean by "http level".

What is it you're trying to achieve? Reuse the handler without it specifying the content type in its signature?

[kirillsalykin]

I'd like to have some generic function which implements some logic for domain entity SignUpRequest and it shouldnt be aware about JSON, I consider details like Json, http code etc - http level, which I believe, should stay at http

[jplatte]

It is possible to write something like this, but it's not easy and I don't have time right now to write down in detail how you would do it. (the basic idea is that you need to write your own version of the Handler trait, and make your wrap function generic over it)

I'm really having a hard time understanding what you're trying to achieve here though. Why are you trying to make your handler functions independent of the HTTP message body content type? Are you looking to support multiple different content types?

[kirillsalykin]

thanks for the answer.

Let me start with answering why:

Why are you trying to make your handler functions independent of the HTTP message body content type?

I'd like to reduce boilerplate a little, cause I know it will be json in - json out.
I was thinking to use these wrappers later to export shape of handlers into typescript, similar to https://trpc.io or https://www.rspc.dev; something like basic version of rspc, fully based on axum router.

Also, it makes handlers simpler (in my understanding), cause they not depend on json or extractors, so can be tested or reused as regular functions (not sure there a big win here, but it feels "cleaner" to me, but probably this is pretty subjective).

the basic idea is that you need to write your own version of the Handler trait

thanks!
It is not urgent and I'd like to figure out this myself, but any help/pointers would be much appreciated!

[jplatte]

Just found this again in my notifications.. W.r.t. testing, you can trivially create a Json(my_value) and pass that to the extractor function.

Other than that side comment: Have you found a solution that suits your needs?

[kirillsalykin]

didnt look much yet, using Json(my_value) is enough currently, would be nice to remove some boilerplate, but not as important.

[2ndDerivative]

It is possible to write something like this, but it's not easy and I don't have time right now to write down in detail how you would do it. (the basic idea is that you need to write your own version of the Handler trait, and make your wrap function generic over it)

I'm really having a hard time understanding what you're trying to achieve here though. Why are you trying to make your handler functions independent of the HTTP message body content type? Are you looking to support multiple different content types?

I have multiple times wanted to use some compile time guarantees in my handler in and outputs elsewhere, e.g. that the output is always Serialize, I imagine this is a similar attempt at it.

[kirillsalykin]

I've finally found time to work on a custom Handler, and indeed it was not easy. I have something like this:

#[derive(Clone)]
pub struct ApiHandler<F, Req, Res> {
    inner: F,
    _marker: PhantomData<(Req, Res)>,
}

impl<F, Req, Res> ApiHandler<F, Req, Res> {
    pub fn new(inner: F) -> Self {
        Self {
            inner,
            _marker: PhantomData,
        }
    }
}

impl<F, Fut, Req, Res, S> Handler<Request<axum::body::Body>, S> for ApiHandler<F, Req, Res>
where
    F: FnOnce(Req) -> Fut + Clone + Send + Sync + 'static,
    Fut: Future<Output = Res> + Send,
    Req: DeserializeOwned + Clone + Send + Sync + 'static,
    Res: Serialize + Clone + Send + Sync + 'static,
    S: Send + Sync + 'static,
{
    type Future = Pin<Box<dyn Future<Output = Response> + Send>>;

    fn call(self, req: Request<axum::body::Body>, state: S) -> Self::Future {
        Box::pin(async move {
            let (mut parts, body) = req.into_parts();
            let state = &state;

            let Json(req) =
                match Json::<Req>::from_request(Request::from_parts(parts, body), state).await {
                    Ok(value) => value,
                    Err(rejection) => return rejection.into_response(),
                };

            let res: Res = self.inner(req).await;
            axum::response::Json(res).into_response()
        })
    }
}

        let app = Router::new()
            .route(
                "/membership/sign-up",
                post(ApiHandler::new(membership::sign_up)),
            )

#[axum::debug_handler]
pub async fn sign_up(input: SignUpInput) -> Boo 
    Boo {
        foo: "bar".to_string(),
    }
}

#[derive(Serialize, Deserialize)]
struct Boo {
    foo: String,
}

of course it doesnt work (otherwise i would ask here : )

error[E0277]: the trait bound `ApiHandler<fn(SignUpInput) -> impl std::future::Future<Output = AuthenticatedResponse> {membership::sign_up}, _, _>: Handler<_, _>` is not satisfied
   --> src/app.rs:55:22
    |
55  |                 post(ApiHandler::new(membership::sign_up)),
    |                 ---- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Handler<_, _>` is not implemented for `ApiHandler<fn(SignUpInput) -> impl std::future::Future<Output = AuthenticatedResponse> {membership::sign_up}, _, _>`
    |                 |
    |                 required by a bound introduced by this call
    |
    = note: Consider using `#[axum::debug_handler]` to improve the error message
    = help: the trait `Handler<axum::http::Request<Body>, S>` is implemented for `ApiHandler<F, Req, Res>`
note: required by a bound in `post`

Would appreciate any pointers to what can be wrong.

[jplatte]

If you could post a link to a repo or gist with a minimal reproducible example, I could take a closer look.

[kirillsalykin]

you can find repro here https://github.com/kirillsalykin/axum-custom-handler

thanks a lot!

[kirillsalykin]

@jplatte i got it working, i forgot to derive Clone on Input and Output 🤦

[kirillsalykin]

Would it make sense to add this an example to axum repo? I can bake a small MR.