We have updated the new plugins pitch for the AWS Lambda Runtime for Swift and would like to get some community feedback about it.
In previous versions, we wanted to avoid introducing new dependencies for the project and we pitched the idea to vend (aka copy/paste) source code from other projects or write low-level code ourselves. This would have implied (re)developing or copying/pasting code to support AWS Signature v4, locating (and maybe refreshing) AWS credentials, making AWS API calls, etc.
We think this is too much effort and risk for the maintenance of the imported code.
We would rather like to use Soto-Core as a basic building block and a new dependency for the plugin (not for the core runtime). Together with Soto-Core, we would generate a minimal AWS SDK providing us with just the AWS API surface we would need to implement the plugins (CRUD fro Lambda functions, Invoke function, some API related to function URL, IAM policies, and S3).
The Soto code generation would be a one-time operation made by the project maintainer, not something that would be part of your builds.
Let us know what you think. Is this the right approach to keep the project small and maintainable in the long term?
I guess the issue with having the generated code in the library is that it requires several layers. In an ideal world it would be integrated and behind a trait so you only build what you need. That might be possible with a custom build plugin that wraps the code generator.
Otherwise bundling core to avoid needing to duplicate everything seems sensible
I propose to generate the required code once for all in a side project and include relevant files as part as the plugin source (and commit them as part of the project). This will be extremely stable, as the AWS API is always backward compatible.
I don't want users to have to deal with the soto code generation plugin and pay the time of that extra step for each build.