Example for futures without async/await

[kathampy]

How do I use futures combinators on the *_async API without async / await? Can you provide an example.

use futures_util::future::FutureExt;
let response = client.send_async(request);
response.then(|| {});

no method named then found for type isahc::client::ResponseFuture<'_> in the current scope

note: the method then exists but the following trait bounds were not satisfied:
&isahc::client::ResponseFuture<'_> : futures_util::future::FutureExt
&mut isahc::client::ResponseFuture<'_> : futures::future::Future
&mut isahc::client::ResponseFuture<'_> : futures_util::future::FutureExt
isahc::client::ResponseFuture<'_> : futures_util::future::FutureExt
help: items from traits can only be used if the trait is in scope
note: the following trait is implemented but not in scope, perhaps add a use for it:
use futures_util::future::FutureExt;rustc(E0599)

[kathampy]

Can this even be used in actix-web handlers with futures-0.1.29?

[sagebind]

It's complaining because your closure signature is incorrect. FutureExt::then accepts a closure with a signature like FnOnce(Self::Output) -> impl Future. FutureExt is a futures-0.3 thing, not futures-0.1. Here's a short example using futures-0.3 (which I'll clean up and add to the examples/ directory shortly).

use futures::future::TryFutureExt;
use isahc::prelude::*;

fn main() -> Result<(), isahc::Error> {
    let future = Request::get("http://example.org")
        .body(())?
        .send_async()
        .map_ok(|response| {
            println!("Status: {}", response.status());
            println!("Headers:\n{:?}", response.headers());
        });

    futures::executor::block_on(future)
}

You should then be able to integrate with actix-web by using the futures::compat module from futures-0.3 to interop between 0.3 and 0.1.

[kathampy]

How do I get the Result of the Future into a variable in the parent scope to continue execution there similar to await, rather than using map_ok? I want to do some computation on the result in the actix-web handler and then generate a response. Is the only wait to chain everything as Futures and return a Future?

What's the difference between futures and futures-util? They both contain the same traits. I see that you've used futures-util within isahc.

[sagebind]

How do I get the Result of the Future into a variable in the parent scope to continue execution there similar to await, rather than using map_ok? I want to do some computation on the result in the actix-web handler and then generate a response. Is the only wait to chain everything as Futures and return a Future?

Yes. That's why await is so cool and combinators are no fun. If you are using combinators, then you have to use combinators. That's how they work, you have to compose everything together into a big Future yourself. (Note that the way async/await works is it actually the same idea, the compiler just creates the giant Future for you.)

Note that there's some methods on FutureExt that don't require closures that produce their own futures, such as FutureExt::map.

I'm not sure how this ties into actix-web exactly as I've never used it, I'd have to see an example of what you are trying to do.

What's the difference between futures and futures-util? They both contain the same traits. I see that you've used futures-util within isahc.

Ah, that. futures is best for apps and examples because it contains everything. It actually just re-exports types from futures-util, futures-io, futures-channel, etc. For libraries using the smaller individual crates if you don't need all of them is preferred to make the dependency tree smaller. In Isahc's case I only needed things in futures-io and futures-util, so I kept it at that because I like to keep the depenency tree trim. 😉 

[kathampy]

actix-web calls this handler when a request hits my server.

fn handle_request(req: HttpRequest, client: web::Data<HttpClient>)
-> impl Future<Item = HttpResponse, Error = Error> {
    // Build request for HttpClient here before using futures.

    // Run send_async() in a future.

    // Do calculations on the result, but I don't want to use futures.
    // Can I wait without blocking the event loop?

    // Return a future with the response.
}

I understand I must convert the final future from futures-0.3 to futures-0.1 before returning it. Do I change my cargo.toml to reference only futures-0.3? How will the handle_request return type be a valid futures-0.1 future then?

[sagebind]

Something generally like this might work (untested):

use futures::future::{self, Either, Future};
// Will have to import futures 0.3 under the alias futures_preview since both 0.1 and 0.3
// are called "futures".
use futures_preview::compat::Compat;

fn handle_request(req: HttpRequest, client: web::Data<HttpClient>)
-> impl Future<Item = HttpResponse, Error = Error> {
    let request = match Request::get("http://example.org").body(()) {
        Ok(request) => request,
        // error must be wrapped in a future
        Err(e) => return Either::A(future::err(e.into())),
    };

    // Begin main future pipeline. Wrap 0.3 into a 0.1 future.
    let future_03 = client
        .get_ref()
        .send_async();
    let future_01 = Compat::new(future_03);

    // Wrap in an Either as before, since `impl Future` requires us to return the same
    // type everywhere.
    Either::B(future_01
        .map(|response| {
            // Do something synchronous with response.
            unimplemented!()
        })
        .and_then(|_| {
             // Do somethng async iand return a HttpResponse.
            unimplemented!()
        }))
}

Really the key part is converting the 0.3 future (really it is std::future::Future now) into a 0.1 future, and then doing normal actix-web things after that. Here's an official post that mentions the compatability layer: https://rust-lang-nursery.github.io/futures-rs/blog/2019/04/18/compatibility-layer.html. I've never used it myself.

Since this is generally more a question about how to deal with futures 0.1 and futures 0.3 compatability, I think other channels might be the best place to get help on this, especially since others are more familiar than I am with both actix-web and the compatability layer.

[kathampy]

Should I build the request for isahc within a future as well, or in the actix-web handler before creating the first future? I'd argue that it's 100% CPU bound blocking code (however brief) that would occupy a CPU core anyway, so does it even matter whether it's done in the actix-web handler blocking the event loop, or in a future?

[sagebind]

I suspect it doesn't matter, but not knowing how actix-web works, I could be wrong.

[kathampy]

In your example, I believe future03 returned by send_async() needs to somehow move or take ownership of client.

I had to wrap the HttpClient in an Arc to separate it from the handler.
let client: Arc<HttpClient> = client.clone();
But then future03 fails with

`client` does not live long enough
borrowed value does not live long enough rustc(E0597)
opaque type requires that `client` is borrowed for `'static`

I annotated the handler with 'a so it's not 'static by default.
Then Either::B fails with

cannot return value referencing local variable `client`
returns a value referencing data owned by the current function rustc(E0515)

[sagebind]

Yes, requests borrow from HttpClient until the future completes. It could be that this lifetime is incompatible with how actix-web uses Data<T>. There's not much I can do to change this though. You might be able to use the global HttpClient Isahc provides as a workaround.

[kathampy]

Can't requests hold the client in an Arc/Rc instead of borrowing?
Can I create multiple static clients globally and access them from the handler through thread_local?

[kathampy]

It's not just incompatible with Data<T>. Even if I create a new client instance inside the handler, I get the same error.
let client = HttpClient::new().unwrap();
This looks like it will be a problem in any asynchronous framework's event handler, if the user wants to use a separate client per thread.

[sagebind]

Can't requests hold the client in an Arc/Rc instead of borrowing?

They could, but that would add a performance overhead.

The future always outlives the handler scope and thus should not borrow the client.

Not necessarily. Async/await definitely encourages using lifetimes instead of Arc, which is a good thing I think. By default async functions return futures that borrow the lifetime of the async function call as well. This is the use-case that Isahc is optimized for. If all goes well async/await will land in stable Rust in about a month; hopefully it doesn't take too long for the ecosystem to adopt the patterns that async/await enable.

If you want to make a case for having ResponseFuture have a static lifetime then I'd create a separate issue for that. No promises that I'd agree with you though. 😉

[kathampy]

So simply using async / await instead of combinators would solve the problem? Can this not be replicated even with futures-0.3 combinators in a futures-0.3-only framework?

In my case I think making a static HttpClient for each thread would work. The global client works, but I want to execute requests on all CPU cores.

[kathampy]

Both reqwest and actix_web::client seem to work fine when using their async APIs in the handler. However they don't have a fraction of the functionality of isahc.

[sagebind]

actix-web would probably have to be revised for this to work, since you intend to borrow the Data for the duration of the response future like you said.

If your goal is 1 client per thread, then yeah using thread_local might be the way to go:

thread_local! {
    static CLIENT: HttpClient = HttpClient::builder()
        // customization
        .build()
        .unwrap();
}

[sagebind]

If you do go down that direction, I'd be interested to hear back about some benchmarks on that approach vs a global client. Personally I'm skeptical that the performance increases will be significant enough, but I'm willing to be proved wrong. 😉

[kathampy]

The server is on a 10 Gb/s pipe and it's only job is to make outbound HTTP/HTTPS requests. I'll find out soon enough if a single core is enough to saturate the network, especially with TLS handshakes. It will probably run into other bottlenecks.