Converting request body to axum::body::Body #513

Umenokin · 2021-11-14T01:12:08Z

Umenokin
Nov 14, 2021

I think my question related more to my inability to fully understand Services and how we can merge/connect with one another.

My problem is:
I have a set of static routes like:

/api/users
/api/projects
etc

Then, I have a set of dynamic routes like:

/admin/* -static file hosting where any route start from /admin serve HTML and assets
/* which is worker which has its own dynamic routing

With API everything is simple, I just use nested routing but for the dynamic part, I am using another service admin_routing looks like this:

impl<ReqBody> Service<Request<ReqBody>> for AdminRouterService
where ReqBody: Send + 'static,
{
    type Response = Response<BoxBody>;
    type Error = Infallible;
    type Future = BoxFuture<'static, Result<Self::Response, Self::Error>>;

    fn poll_ready(&mut self, cx: &mut Context<'_>) -> Poll<Result<(), Self::Error>> {
        Poll::Ready(Ok(()))
    }

    fn call(&'a mut self, req: Request<ReqBody>) -> Self::Future {
        println!("Admin route handler");
        let mut console = self.console.clone();
        let mut worker = self.worker.clone();

        Box::pin(async move {
            let res = if req.uri().path().starts_with(WEB_ROOT) {
                let res = console.call(req).await.unwrap();
                res
            } else {
                let res = worker.call(req).await.unwrap();
                res
            };
            
            Ok(res)
        })
    }
}

Just with the console, everything works fine but the worker is also have routing (not to mention that after 0.3.x update none of it would work, but worked before):

pub struct WorkerService<S> {
    router: S,
    worker: Arc<Worker>,
}

impl<S, R> Service<R> for WorkerService<S>
where S: Service<R>,
{
    type Response = S::Response;
    type Error = S::Error;
    type Future = S::Future;

    #[inline]
    fn poll_ready(&mut self, cx: &mut Context<'_>) -> Poll<Result<(), Self::Error>> {
        self.router.poll_ready(cx)
    }

    #[inline]
    fn call(&mut self, req: R) -> Self::Future {
        self.router.call(req)
    }
}

Back to the problem let res = worker.call(req).await.unwrap(); The type of the request is Request<ReqBody> while worker expects to accept axum::body::Body. I guess, the dumb question would be "how to convert Request<ReqBody> to axum::body::Body.

Though I think the bigger problem is that documentation focuses on convenience using Services and minimalistic non-macros APIs which is true but as soon as you need to make something more advanced it is really hard to connect all pieces involved.

@davidpdrsn is always helping out but I think there are some foundational docs missing. How to connect services assuming that they are all generics and end up having different Request/Response types. For example, I have been using BoxBody from http crate and struggling to understand some issues, then I checked axum::body and found a pretty clear comment:

/// This is used in axum as the response body type for applications. It's
/// necessary to unify multiple response bodies types into one.

Which helped but would've been better if I wouldn't have to scroll through sources to understand.

And I will be happy to help with documentation (though my English grammar sucks) but for that I need to have clear understanding myself.

Answered by davidpdrsn

Nov 14, 2021

If you're in a spot that requires converting a generic request body into a axum::body::Body then I'd say your approach is wrong. Its not something you should have to do. So this feels like an XY question.

Is there a reason you're writing tower services directly instead of async handler functions? If that is possible I would highly recommend doing that instead as its way easier.

You also don't have to use a generic parameter for the request body. Doing this should just work:

impl<S> Service<Request<Body>> for Foo<S>
where
    S: Service<Request<Body>>,

Similar to whats shown here.

This wont work if you have middleware the change the request body but such middleware are very rare. For examp…

View full answer

davidpdrsn · 2021-11-14T10:15:09Z

davidpdrsn
Nov 14, 2021
Collaborator

If you're in a spot that requires converting a generic request body into a axum::body::Body then I'd say your approach is wrong. Its not something you should have to do. So this feels like an XY question.

Is there a reason you're writing tower services directly instead of async handler functions? If that is possible I would highly recommend doing that instead as its way easier.

You also don't have to use a generic parameter for the request body. Doing this should just work:

impl<S> Service<Request<Body>> for Foo<S>
where
    S: Service<Request<Body>>,

Similar to whats shown here.

This wont work if you have middleware the change the request body but such middleware are very rare. For example there are currently no middleware in tower-http that change the request body, though we're thinking about adding one.

In terms of documentation I think you're right. Tower has a reputation of being hard to understand and while I think we're in a better spot now than a year ago, we still have work to do. However I don't feel tower needs more API documentation (in the docs.rs sense). We already have:

Inventing the Service trait motivates why tower exists in the first place and why the Service trait looks the way it does.
Building a middleware from scratch explains, in detail, how to build a protocol agnostic middleware from scratch as well ass discussing the trade-offs you have to make. Its aimed at users who wanna write middleware similar to those found in tower and tower-http.
The tower::Service docs have several examples as well.

Its quite hard to write good "how it all fits together" docs in generated API docs, especially when your API is split across a few crates (tower, http, tower-http, http-body, hyper, axum). Depending on the level of abstraction you're at you might also run into more generics than you used to. I don't think the generics are inherently bad but unless you come from haskell or scala there might be some learning curve to it.

Personally I would like to write more blog posts (or streams) about solving concrete problems with tower. The hope being that after people have read a bunch of them they would have a deeper understanding and know which tools to apply where. But figuring out how to explain this stuff in a way thats easy to understand, is hard. Its not something I have bandwidth for myself at the moment unfortunately.

2 replies

Umenokin Nov 14, 2021
Author

Thanks again @davidpdrsn ! I managed to fix the same way you recommended thanks to a great article: https://www.fpcomplete.com/blog/axum-hyper-tonic-tower-part2/

As for why I am using services... well now while I am a bit more experienced with Services I would probably say that it was my mistake. The reason is that I thought that I would create a bunch of services, create them during initialization and call them without creating them every request again. Following examples, I realized that we cloning them on every request anyway, so in that sense, there was no point making those services or at least making complex relationships.

My problem is that I used C++ 12 years ago last time and for the past 10 years was mainly in JS, TS, and Dart realm, so you probably can guess to what type of abstractions I got used to. So the project I am currently working on requires me to learn Rust, Tokio, Axum, Wasmtime, etc. Plus, I do think that Rust developers made a big mistake explaining rust from OOP perspective. Saying that Trait is like Interface is one thing but it is a very misleading explanation specifically in the rust ecosystem.

And I would say that I would probably already give without your help. Thank you for your help!

davidpdrsn Nov 14, 2021
Collaborator

That sounds good! And yeah I generally wouldn't recommend over abstracting early on, things get pretty hairy pretty quickly.

Plus, I do think that Rust developers made a big mistake explaining rust from OOP perspective. Saying that Trait is like Interface is one thing but it is a very misleading explanation specifically in the rust ecosystem.

Well a trait is sorta like an interface. However its more accurate to say they're like haskell or scala typeclasses but most people probably aren't familiar with those 😞 So from a teaching perspective I think rust made the right decision on that.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Converting request body to axum::body::Body #513

{{title}}

Replies: 1 comment 2 replies

{{title}}

{{title}}

{{title}}

Select a reply

Converting request body to axum::body::Body #513

Umenokin Nov 14, 2021

Replies: 1 comment · 2 replies

davidpdrsn Nov 14, 2021 Collaborator

Umenokin Nov 14, 2021 Author

davidpdrsn Nov 14, 2021 Collaborator

Umenokin
Nov 14, 2021

Replies: 1 comment 2 replies

davidpdrsn
Nov 14, 2021
Collaborator

Umenokin Nov 14, 2021
Author

davidpdrsn Nov 14, 2021
Collaborator