Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Aligning behavior with other AWS SDKs #1567

matthewkmayer opened this issue Oct 31, 2019 · 1 comment

Aligning behavior with other AWS SDKs #1567

matthewkmayer opened this issue Oct 31, 2019 · 1 comment


Copy link

@matthewkmayer matthewkmayer commented Oct 31, 2019

As Rusoto continues to mature and gain users, we should keep in mind how much this project differs from other AWS SDKs.

I'd like to set a high level goal of getting Rusoto closer to how other AWS SDKs behave. There are some differences we can't avoid due to Rust and cargo, but we should be move to match how other AWS SDKs behave as much as feasible.

How do others feel? 😄


This comment has been minimized.

Copy link

@softprops softprops commented Oct 31, 2019

I see this as a very practical goal that benefits folks already familiar with aws ecosystem potentially making the transition to rust. The more familiar we can make interacting with aws services feel, the less friction organizations will likely run into when experimenting with rust in an professional setting.

I see two items that challenge that adoption that make rusoto fall below standard expectations for aws SDKs. Both I've worked around both in other crates and projects with rusoto but both likely are leave a betaware first impression on organizations toedipping into rust that don't have the luxury of someone that happens to be familiar with both aws service details and rust at the same time.

  1. default retry strategies. I put this first because robustness is not a optional feature for companies relying on api services to make their business run. These are so we'll integrated with other aws SDKs that most engineers don't have to think about them and that is the point.

  2. auto pagination interfaces. Any list-xxx API is going to incur some amount of boilerplate. In most cases it's is exactly the same boiler plate. Engineers used to interacting with aws SDKs are used to eliding over this boiler plate as quality of life enhancement.

Luckily the information for both of these is available into the metadata used to generate the current interfaces in rusoto.

I took an initial stab at autopagination a while back but got a but stuck on using the botocore descriptions to interrogate responses for pagination tokens in a few corner cases. That's solvable but I know think it would be wise to see what the std lib story for async streams will look like. The futures crate had a nice streams API but now that the std lib is evolving is async story, streams maybe unstable territory.

I'd like to look at retries next. Some work here may be more focused in ironing our weak spots in error deserialization. In most many cases, knowing what can be retired depends on knowing what error is returned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.