Impossible to generate clients for non-aws services due to dependency on aws.api#Service trait

[Petroniuss]

Describe the feature

Looks like the only way to generate go smithy clients is to build both projects source - codegen: Move protocol generators out of aws-sdk-go-v2 into smithy-go:

• smithy-go
• aws-sdk-go-v2

However, it's not possible to generate basic http clients without modifying source of aws-sdk-go-v2. The reason for that is that most GoIntegrations specific to AWS residing in aws-sdk-go-v2 do something similar to lines below:

 ServiceShape serviceShape = settings.getService(model);
 return serviceShape.expectTrait(ServiceTrait.class).getSdkId();

This causes the code generation to fail if the service isn't annotated with aws.api#Service.

Relevant parts of the stacktrace showing the problem:

software.amazon.smithy.model.node.ExpectationNotMetException: 
Expected shape example#ExampleClient to have a trait 
software.amazon.smithy.aws.traits.ServiceTrait...

...
at software.amazon.smithy.model.shapes.Shape.lambda$expectTrait$0(Shape.java:332)
   at java.base/java.util.Optional.orElseThrow(Optional.java:403)
   at software.amazon.smithy.model.shapes.Shape.expectTrait(Shape.java:332)
   at software.amazon.smithy.aws.go.codegen.AwsSdkServiceId.processServiceId(AwsSdkServiceId.java:33)
   at software.amazon.smithy.go.codegen.ServiceGenerator.generateMetadata(ServiceGenerator.java:109)
   at software.amazon.smithy.go.codegen.ServiceGenerator.generate(ServiceGenerator.java:96)

Use Case

Trying to generate go clients using smithy for non-aws services.

Proposed Solution

Would it be possible to first check if a service has the aws.api#Service trait and if it doesn't then skip applying the integration? This is how I've seen other aws smithy repos do it. Of course I'd prefer to just use smithy-go but this seems to be blocked/not prioritized.,

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

AWS Go SDK V2 Module Versions Used

2024-02-28 release

Go version used

1.20

[lucix-aws]

This repository's codegen is not consumer-facing, and is not written to be reusable for arbitrary smithy models. Its sole purpose is to effect codegen of AWS SDKs. The only "artifact" produced by this repository is the runtimes and service clients for public AWS services.

With that context, the integrations are correct as written, as the trait is necessary to correctly generate AWS service clients.

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.

[Petroniuss]

Hi @lucix-aws,
thanks for your answer - makes sense.

Would you be able to point me what would be the correct way to consume smithy-go - would depending on smithy-go and implementing restJson protocol using tools provided in smithy-go be a good idea?

[lucix-aws]

would depending on smithy-go and implementing restJson protocol using tools provided in smithy-go be a good idea?

I can't say it would be. Protocol generation is complex by nature. It's all been implemented here, but as written it's tightly coupled to the SDK's own runtime dependencies in a way that's not trivial to untangle. Event streaming is the biggest offender and is the primary blocker for migration - the entire event stream runtime is aws/protocol/eventstream, which the codegen is tied to.

I truly wish I had a better answer for you, but this is the state of things at this time. I make a point to work on refactors and incremental improvements to smithy-go's own codegen as I work on the SDK, but at large it is currently not receiving direct contributions due to lack of capacity.