Support non-AWS client generation via a Smithy SDK #500
Labels
enhancement
New feature or request
no-auto-closure
We do not want this issue to be automatically closed.
This is the top-level issue to cover generating clients from any Smithy models, not just AWS service. Such a client generator will be referred to as a "Smithy SDK" in this issue.
Currently AWS SDKs for Kotlin are generated from a program consisting of three primary layers:
smithy-kotlin
(codegen, rt)aws-sdk-kotlin
(codegen, rt)aws-crt-kotlin
(rt)When an AWS SDK is generated in Kotlin, some runtime and codegen artifacts are produced specifically to support AWS features that would not be appropriate or generally applicable to non AWS services. Features such as AWS region, signing details, and AWS credential file parsing are all examples of functionality that non-AWS service clients would not need.
There are also missing aspects for general purpose clients. For example, the ability to specify endpoints or provide custom auth schemes.
Another complexity is in where various things are organized in our projects. At this time, there is no generic Smithy protocol. There is no spec or implementation that can provide serialization outside of what is specified by AWS protocols (defined in Smithy). This means that some AWS protocol logic will need to exist in the Smithy SDK, however our current architecture places all protocols in the aws-sdk-kotlin repo. This means that either the Smithy SDK will include code from
aws-sdk-kotlin
or the subset of protocols required to generate clients (restJson
,awsJson1_0
) will need to migrate down tosmithy-kotlin
.AWS services have strong guarantees around how they are allowed to change over time, optimizing on the customer experience and avoiding situations which cause customers to have to update their code to work with new features provided by SDKs. This constrains us in some ways, for example how we treat required fields as being nullable in the AWS SDKs. As developers of various Smithy-based SDKs may have their own opinions or requirements about how Kotlin should be generated from service models, a more granular configuration needs to be expressed via the plugin settings.
Acceptance Critera
Community Note
The text was updated successfully, but these errors were encountered: