Provide a async API for different async runtime crates and also a sync API

[howard-quantrend]

Maybe the sdk could support both popular async runtimes, tokio and async-std using feature flags? In my case, our project only uses the async-std crate, so we need to rewrite the necessary parts of the Rusoto crate ourselves using async-std runtime. It will be great if the aws-sdk-rust supports both runtimes using feature flags, and even better if it provides a blocking sync API too, to support different kind of projects. Actually, this is what the MongoDB rust driver does. Thanks.

[rcoh]

You can actually use async-std today by providing your own implementation of the HttpService trait.

If there's enough customer interest, we may consider providing first-class support, but it's worth noting that the workaround exists today. In the current SDK, you would still need to run a 1-threaded Tokio runtime to support retries (which have not yet been made runtime agnostic, although they are planned to be)

[howard-quantrend]

Sorry, can you explain more about the part "you would still need to run a 1-threaded Tokio runtime to support retries" part?

[rcoh]

There is some code (that will hopefully eventually go away or be removable via cfg) that uses tokio::time::sleep to support retries. This requires a dependency on at least the time & rt features of Tokio. A Tokio runtime must also be started in your process (but it will only use one thread—it can happily coexist with async-std).

[rcoh]

A sync API is also an interesting option, I'll start a separate discussion for that.

[per-oestergaard]

Hi @rcoh, any news on the sync API? Learning Rust, my first larger project is moving data from an web API to an RDS table. However, as everything has to be async, I lost UI debugging features in vscode, so a sync version would be appreciated (or async debugging support in vscode).

[rcoh]

Hi @per-oestergaard — we don't have an immediate plans for a sync API. Unfortunately, I'm not sure a sync API would even work with VSCode. I suspect it would be architected similar to the reqwest sync API that is still based on Tokio and very careful use of block_on to avoid deadlocks. For debugging you might try tracing

[jmklix]

Created feature request here and locked this discussion