Refactor SDK Internal to be Async

[kneekey23]

Hi all,

I wanted to start a discussion here about something that would affect our public APIs and the future of this SDK. Since Apple has backported async language features to previous versions of Apple platforms that we as an org would like to support, we feel comfortable refactoring the SDK internals to remove all use of completion handlers and remove the public completion handler apis as well. Post refactor, we would ONLY offer the async APIs in the SDK and completion handlers would be gone. Before we go down this road since it is very much a one way door, we would LOVE community input here. Do you guys have concerns from a business standpoint or a technical standpoint with this decision? From an AWS perspective, we are in full support of this decision but our customers come first. Please let us know below. :)

[gwynne]

Speaking strictly from my own personal opinion, I think this is an awesome idea! Async/await code is considerably easier to both write and read than any other paradigm I've encountered - and it seems to me that this is exactly the kind of thing that back-deployment support was intended to enable.

[masters3d]

Seems to me that a deprecation story would be more desirable from an api consumer point of view.

[kneekey23]

Not sure what you mean here. This SDK is currently in alpha, we can change any of our APIs right now at any time without the need for this kind of story. It's not yet a production SDK where things need to be deprecated, everything is subject to change based on customer feedback or change in business requirements until this SDK is GA.

[jdmcd]

I think this is a great idea - especially since the goal of the community seems to be moving in the direction of async-first over the coming months. Thanks for you and your team's hard work on this!

[patagoniacode]

Hi Nicki, totally agree with the removal of completion handlers and the offering of only async APIs.
Thanks for the wonderful work!

[kneekey23]

it is our pleasure! thanks for the response!

[idelfonsog2]

In my opinion:

It would be better to only support async/await. It is not imaginable developers using the 'completionHandlers' api just creating wrappers around them and having those around could add confusion to new comers of the api.

[vi4m]

Async API's are the way to go, so ... don't hesitate to drop old APIs when needed.

[GitHubbler]

Drop completion handlers--they have tortured me enough.

[kneekey23]

FYI folks, all the PRs are up for this change to happen, I am just blocked on a few bugs in the backport for Big Sur and some lacking things in XCTest on Linux so can't merge them yet. but the work is done! hopefully soon as Apple releases more fixes and new things.

[ToddHoff]

Curious if these changes are in the AWS SDK for Swift (Developer Preview)?

[kneekey23]

Not yet, still waiting on xctest support for async on Linux but that's the last thing! All the other bugs I mentioned have been fixed. I'm hoping to get this merged and released by the end of month but waiting on a nightly tool chain release first. Fingers crossed we see one soon!

[kneekey23]

In the meantime tho if you just use the async apis in the Sdk currently they won't change once this gets merged. Just the internals of the Sdk are changing. So feel free to use those calls now

[kneekey23]

FYI all PRs have now been merged! Release is about to go out and will be version 0.2.0! @ToddHoff