Pre RFC: A sync API

[rcoh]

In some cases, dealing with an async API is an unnecessary hassle. This discussion is a place to discuss the customer requirements for a sync API as well as general design considerations (eg. separate cargo feature, how does this work with streaming data, etc.)

[kingpalethe]

Yes, we are really looking for a way to use SQS without tokio, without any of the async. Async in Rust is extremely challenging to use with rust libraries that use C FFI. So far, we haven't found any examples of anyone using SQS synchronously, without Tokio or another async library.

[per-oestergaard]

I can see it addressed here. Upvote for a sync version (as all other AWS SDKs seem to have)

[decatur]

Having to choose between sync and async, it all depends.

I guess we need a couple of use cases with best practices (idiomatic) in Rust, including performance and usability benchmarks.

One use case is the high traffic web server, where upon each downstream request another upstream request against an AWS service is made.
The current async Rust SDK then is (supposedly) a no-brainer, in part because the web server is already using async, most likely tokio.

In another use case, we are event sourcing from S3 buckets and distribute the events by category to (say 100) compute tasks.
We did this with Rusts 1:1 threads all right, until we needed a small monitoring web server with a healthz endpoint.
After adding the warp async server, compute time increased by factor of 1.3 (beats me), executable size by a factor of 3 (due to the async runtime).

[jmklix]

Created feature request here and locked this discussion