aws-sdk-rust [request]: Separate, stable crate for AttributeValue

A note for the community

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue, please leave a comment

Tell us about your request

Currently aws_sdk_dynamodb::model::AttributeValue and aws_sdk_dynamodbstreams::model::AttributeValue are distinct types, even though they are identical.

The definition for these two hasn't changed since aws-sdk v0.0.23-alpha.

Tell us about the problem you're trying to solve.

The ecosystem currently has at least 5 different definitions of AttributeValue.

That number is much larger if you consider that rustc considers each version to be a different type (e.g. aws_sdk_dynamodb::model::AttributeValue from aws_sdk_dynamodb version 0.9 is distinct from aws_sdk_dynamodb::model::AttributeValue from aws_sdk_dynamodb version 0.8).

I believe it would be hugely beneficial for the community if there were one definition of AttributeValue in a standalone stable (1.0) crate, so that every crate that works with attribute values could depend on it and use AttributeValues interoperably.

To avoid a https://xkcd.com/927/ situation, I haven't created a standalone crate for this. I'm impartial about who maintains it. It seems most reasonable to me that the aws-sdk-rust team would own it. But I would also be happy to extract the aws-sdk-rust code into a separate crate and maintain it if aws_sdk_dynamodb would use it.

Are you currently working around this issue?

I maintain serde_dynamo, the library for converting complex AttributeValues into structured data.

We work around this issue by creating feature flags to support every different version of AttributeValue. See https://docs.rs/serde_dynamo/latest/serde_dynamo/#features for more information on the approach.

Right now, we have to track all 5 crates and make a new release, with new feature flags, every time one of them updates.

We use macros to derive the various implementations because, although aws_sdk 0.8's AttributeValue and aws_sdk 0.9's AttributeValue (for example) are exactly the same, they are distinct according to the compiler, so we need separate implementations.

If there were a standalone stable 1.0 crate that contained the definition of AttributeValue, then serde_dynamo would have only one implementation, no need for feature flags, and no need for the implementation macros. And more importantly, support wouldn't need to be added to serde_dynamo after a new release of aws_sdk (a task that isn't hard or all that time consuming from a technical perspective, but still a chore that needs to get done and doesn't always get done immediately).

Users of serde_dynamo would benefit significantly because 1/ support for the new version of aws_sdk would be available the second that aws_sdk has a new version, and 2/ they wouldn't have to bump a feature flag every time they bumped their version of aws_sdk.

Additional context

If the aws-sdk-rust team is interested in this proposal, I will also try to work with the aws lambda events team for the benefit of the community.

I will also work with the rusoto team, but as rusoto is in maintenance mode, I could understand them not adopting.

I'd be willing to submit a PR to make this happen if requested.

Mar 26 '22 12:03 bryanburgers

The reason for the separation of these types is that they're only the same right now. If we unify these types, that's a commitment to keep them unified for the rest of the lifetime of AWS Rust SDK v1. These types are controlled by the various service teams and we (the Rust SDK team) are not comfortable making a commitment that these types will always be identical. However, given that this isn't a great user experience, I'll convene a team meeting and see if we can come up with a better way to do things.