The AWS SDKs are generated code. I’m looking at the C++ SDK documentation and it says:
Allows you to build any arbitrary clients based on the api definition. Simply place your definition in the code-generation/api-definitions folder. Then pass this arg to cmake. The cmake configure step will generate your client and include it as a subdirectory in your build. This is particularly useful if you want to generate a C++ client for using one of your API Gateway services.
This is a new area for me to explore. I’m wondering if serverless could be extended to generate input files for the SDK generator? I could see two applications, first generate input files for your API gateway functions.
Second, provide a list of the AWS APIs you actually use and then generate a minimal input file for the SDK generator with just those functions in it. For example, I use a single function from Cognito. In the current SDK setup this causes support for about 400 Cognito related functions to be added to my app. This is repeated across multiple AWS services adding 50MB+ of unused bloat in my client app.
Better would be for me to put a list of AWS APIs I use into my yaml (plus the API gateway functions), then serverless could create a custom generator input file that would generate an SDK containing only the functions I need. (the linker does not eliminate the bloat since the generated APIs are all tied together into a single constructor, the unused functions have to be eliminated at the generator step).
So I could see a new serverless command like ‘sls generate-sdk’ which generates a new file in aws-sdk-cpp/code-generation/api-descriptions. Then I run cmake on the SDK and voila I have a custom SDK with only the minimum set of functions I need.
Note that sls does not need to know all about the AWS API. All of the APIs are defined in aws-sdk-cpp/code-generation/api-descriptions. sls would read those API definitions and then spit out a new file that deletes all of the unneeded ones. So in my case, it would read the Cognito definitions file and spit out a new file containing only the single definition that I am using.