[request]: Please don't duplicate types that exist for multiple services

[dcormier]

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
As more services are supported by the SDK, please don't duplicate types common to multiple services. The type that brought this to my attention is the DynamoDB AttributeValue type.

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
As a current user of Rusoto for DynamoDB and DynamoDB Streams, I have been frustrated that they have separate (but identical) implementations for the AttributeValue types used to represent data in both of those services.

Rusoto has the DynamoDB type here, while the DynamoDB Streams type is here.

Are you currently working around this issue?
I have a function that converts from a rusoto_dynamodbstreams::AttributeValue to a rusoto_dynamodb::AttributeValue so that I can use existing tooling for rusoto_dynamodb::AttributeValue (like serde_dynamo). So wherever I need to deal with a rusoto_dynamodbstreams::AttributeValue, I convert it first, then deal with it like the rusoto_dynamodb::AttributeValue it should be.

Additional context
I know this isn't yet a problem in this repo. I just want to make sure that it doesn't become one. Seeing the AttributeValue type defined in dynamodb::model made me concerned that dynamodbstreams::model::AttributeValue might exist in the future.

[rcoh]

Unfortunately, in the general case, we can't share types between services. Although the types are currently identical, on the AWS side these types aren't actually coupled (eg. in the future, dynamodbstreams could add another variant to attribute value that wasn't present in dynamodb::AttributeValue). We also can't introduce a dependency between separate services.

However, I absolutely agree that we should try to help customers use these types between services without too much friction (perhaps by providing an additional crate like dynamodb-compat that provides the Into<T> implementations?) I'm going to move this issue to a discussion where we can discuss what the ideal user experience is.

[sagebind]

If there is a clear direction of dependency, then you could accomplish this by using crate features. For example, the dynamodb crate might have a dynamodb-streams-conversions feature which, when enabled, would provide From implementations that convert from DynamoDB Streams types into DynamoDB types. (Naturally this would also pull in the dynamodb-streams crate as well, but only if you opted in to the feature.)