Writer based ResponseBody

[mineichen]

• I have looked for existing issues (including closed) about this

Feature Request

Motivation

I'm using async_zip to send data directly to the client. async_zip::core::ZipFileWriter::new accepts a param, which implements AsyncWrite. Afterwards, i can asynchronously add files to the ZipFileWriter, and the encoded/compressed data is written to the underlying writer. Unfortunately, I couldn't get a hand on a writer for the HttpBody.

Proposal

I came up with a new IntoResponse type, which accepts a closure that returns a future. As long as the future is not finished, it's able to write data to the writer. You can find a naive implementation here. The usage of that type looks like this:

IoStreamBody::with_writer(move |mut w| {
    async move {
       w.write_all(b"Hello").await?;
       Ok(())
    }
}),

This will allow easy integration with async_zip and it will potentially be easier to imlement allocation-free data-streams, as we never need to represent the data to be returned as a owned byte-slice.

Alternatives

Just leave this to the user, as it can be implemented today.
I don't know, how important backward compatibility is... Maybe It could be implemented with AsyncFn instead?
Such a IntoResponse-Type could also life in the axum-extras project. The Error type should most likely not be anyhow::Error (as in the poc implementation).

[mladedav]

You don't need a new type, you can just use ReaderStream to convert your Reader into a Stream and then Body::from_stream.

Does that solve your issue?

[mineichen]

It could be part of the implementation, but there is more to it.
I don't just have a AsyncRead, but I have to create one, e.g. with piper. But now I have drive the future which fills the pipe somewhere. In my implementation I do this as part of the Stream( the easiest way is, to just spawn a tokio task, but in a complete implementation I have to handle Errors/Panics of this task so it can be related to the Request and is not just a "global error").

I aggree, that this doesn't have to be directly related to axum, but outside axum, we need to go through a indirection (e.g. Piper), but axum has the possibility to expose the writer with access to the RequestSocket, if it's implemented by axum itself and not in axum-extra.

It would be another paradigm, and other Languages/Frameworks (e.g. Dotnet) allow you to write to the http-body instead of returning a value from the handler which is then written by the framework. It would be nice to have something like that, because it wasn't obvious to me how I can use AsyncFileWriter without a intermediate Buffer. A junior dev might even think, that this is not possible with axum.

[jplatte]

I think this would make a nice convenience feature, if not solving problems not easily solved with ReaderStream.
@mladedav how strongly do you feel that we shouldn't have this?

[mladedav]

I wouldn't say I'm opposed to having it. I just don't see the benefit (yet). It seems to me as a way to write generators (or alternative to stream!) with a special write method instead of yield. Maybe I misunderstood something?

But I get that someone might prefer the writer style. We can put something like that into axum-extra and see what it looks like. I don't think there's any performance benefit to having it directly in axum as the last comment seems to have suggested.

[jplatte]

Why axum-extra? This only needs a new Body constructor akin to from_stream, right?

[mladedav]

It just feels... extra. I don't really have a reason, I just thought this is more of a convenience that would go there.

[jplatte]

I imagine the implementation is going to be pretty simple, so if that is the case I think it makes most sense as a Body constructor.

But if it was to increase the complexity of Body noticably, maybe you're right and it should go into axum-extra.

PRs welcome :)

[mineichen]

Such a helper would unlock using push-based libraries... AsyncZip, afaik doesn't provide a way to turn a AsyncRead into a Zipped AsyncRead... It only has the async_zip::core::ZipFileWriter::new() method which accepts a writer... Afterwards, you have to actively write data to the ZipFileWriter.

Having such a AsyncRead wrapper, which turns unzipped bytes into zipped bytes would be a nice extension for the AsyncZip crate though...

[mladedav]

I took a look at the usecase once more and what I think you can do is this:

async fn handler() -> impl IntoResponse {
    let (producer, consumer) = tokio::io::duplex(4096);
    let mut zip_writer = async_zip::tokio::write::ZipFileWriter::new(producer.compat());
    tokio::spawn(async move {
        // A task that generates the data to be zipped
        for i in 0..10 {
            let data = b"This is an example file.";
            let opts = ZipEntryBuilder::new(format!("{i}.txt").into(), Compression::Stored);
            zip_writer.write_entry_whole(opts, data).await.unwrap();
        }
        zip_writer.close().await.unwrap();
    });

    Body::from_stream(ReaderStream::new(consumer))
}

Do you have an example of how you're using the IoStreamBody with the zip crate? Because of the API it has you still have to concurrently poll whatever future generates data for the zip implementation and the channel over which it returns the data to you, right?

[mineichen]

Your example summarizes the inconvenience: Someone has to poll the writer, but tokio is not always available, so it cannot be the a spawned task... I implemented it here, so the output-stream is polling that future and also handles the error, so you don't have to use unwrap in the future... I'll get rid of the external crates and create a pull request

[mineichen]

The Body struct is defined in axum-core. To add a with_writer method, I see four options to move forward:

• Create a custom AsyncWrite implementation in axum_core, which sends Result<Bytes, axum::Error> into a channel. This would require adding futures-channel dependency or even handroll channel ourself
• Add a dependency to the lightweight smol-rs/piper to axum_core (my preference)
• Implement with_writer as an extension trait on Body within axum or axum-extra and add piper-dependency there
• Add a helper function like to_bytes, which would not be easy to find, but matches the style of to_bytes

Please tell me, what you consider the most appropriate way to move forward