|
| 1 | +# AWS Custom Resource SDK Adapter |
| 2 | + |
| 3 | +The AWS custom resource SDK adapter is an internal collection of tools built to maintain compatibility with the contracts defined for `AwsCustomResource` and the current AWS SDK version. `AwsCustomResource` can be used where a single API call can fill a gap in CloudFormation coverage by allowing a user to specify a single API call specific to create, update, and delete stack events. Users specify a `service`, an `action`, and `parameters` as part of the `AwsSdkCall` interface which are used to dynamically invoke the API. Since `AwsCustomResource` was created while SDKv2 was active, it implicitly inherited the SDKv2 contract. As a result, migrating to newer SDK versions will result in breaking changes in the `AwsCustomResource` construct. In its current state, the AWS custom resource SDK adapter contains tooling that allows `AwsCustomResource` to make API calls using SDKv3 and return the associated response. These tools are related to: |
| 4 | + |
| 5 | +* Input type coercion |
| 6 | +* Response coercion |
| 7 | +* Naming normalizaion |
| 8 | + |
| 9 | +## Input Type Coercion |
| 10 | + |
| 11 | +In general, input types expected by SDKv3 are more restrictive than what was expected by SDKv2. One such example is the regression to number types with respect to AWS SDKv2. More specifically, in SDKv2, number types that are accidentally passed as strings will be silently converted to the right type. SDKv3, however, will not do the conversion which causes the server call to fail because of mismatched types. For example, |
| 12 | + |
| 13 | +**SDKv2** |
| 14 | + |
| 15 | +```ts |
| 16 | +const codedeploy = new AWS.CodeDeploy({ region: 'eu-west-1' }); |
| 17 | + |
| 18 | +const input: AWS.CodeDeploy.CreateDeploymentConfigInput = { |
| 19 | + deploymentConfigName: 'testtest', |
| 20 | + computePlatform: 'Lambda', |
| 21 | + trafficRoutingConfig: { |
| 22 | + type: "TimeBasedLinear", |
| 23 | + timeBasedLinear: { |
| 24 | + linearInterval: "1" as any, // The type says 'number' but we're forcing strings here |
| 25 | + linearPercentage:"5" as any, |
| 26 | + }, |
| 27 | + }, |
| 28 | +}; |
| 29 | + |
| 30 | +// Following call happily succeeds |
| 31 | +console.log(await codedeploy.createDeploymentConfig(input).promise()); |
| 32 | +``` |
| 33 | + |
| 34 | +**SDKv3** |
| 35 | + |
| 36 | +```ts |
| 37 | +const codedeploy = new CodeDeploy(); |
| 38 | + |
| 39 | +const input: CreateDeploymentConfigCommandInput = { |
| 40 | + deploymentConfigName: 'testtest', |
| 41 | + computePlatform: 'Lambda', |
| 42 | + trafficRoutingConfig: { |
| 43 | + type: "TimeBasedLinear", |
| 44 | + timeBasedLinear: { |
| 45 | + linearInterval: "1" as any, // The type says 'number' but we're forcing strings here |
| 46 | + linearPercentage:"5" as any, |
| 47 | + }, |
| 48 | + }, |
| 49 | +}; |
| 50 | + |
| 51 | +await codedeploy.createDeploymentConfig(input); |
| 52 | + |
| 53 | +// The above call fails with the following message: |
| 54 | +'SerializationException: STRING_VALUE can not be converted to an Integer' |
| 55 | +``` |
| 56 | + |
| 57 | +Another example is the regression to blob types with respect to SDKv2. More specifically, in SDKv2, input fields marked as blob types used to permissively accept strings, buffers, and uint8arrays. In SDKv3, these same fields now only accept uint8arrays. |
| 58 | + |
| 59 | +In response, the [`Coercer`](./lib/coerce-api-parameters.ts) class was created to coerce input parameters to the type expected by SDKv3. At a high-level, this class coerces parameter types using a state-machine generated using smithy models. The state-machine is gzipped to save bytes and the gzipped representation can be seen [here](./lib/parameter-types.ts). |
| 60 | + |
| 61 | +## Response Coercion |
| 62 | + |
| 63 | +In some cases, API call responses for SDKv3 differ from API call responses for SDKv2. One example is streaming vs. buffered responses. More specifically, SDKv3 prefers not to buffer potentially large responses. For node.js, you must consume the stream or garbage collect the client or its request handler to keep the connection open to new traffic by freeing sockets. For example, |
| 64 | + |
| 65 | +**SDKv2** |
| 66 | + |
| 67 | +```ts |
| 68 | +// this buffers (consumes) the stream already |
| 69 | +const get = await s3.getObject({ ... }).promise(); |
| 70 | +``` |
| 71 | + |
| 72 | +**SDKv3** |
| 73 | + |
| 74 | +```ts |
| 75 | +// consume the stream to free the socket |
| 76 | +const get = await s3.getObject({ ... }); // object .Body has unconsumed stream |
| 77 | +const str = await get.Body.transformToString(); // consumes the stream |
| 78 | +``` |
| 79 | + |
| 80 | +Users are able to retrieve values returned as a result of API calls they’ve defined while using the `AwsCustomResource` construct. To be retrievable, the response values must be strings. With SDKv3, the stream must be fully consumed to a string before the custom resource exits. Thus, response coercion was built as another tool in the AWS custom resource SDK adapter. Return type coercion exists in the [api-call](./lib/api-call.ts) file and the logic is implemented in the `coerceSdkv3Response` function. |
| 81 | + |
| 82 | +## Naming Normalization |
| 83 | + |
| 84 | +Originally, the `AwsCustomResource` construct advertised that the `service` argument defined in the `AwsSdkCall` interface could be in any one of the following formats: |
| 85 | + |
| 86 | +* The SDK v2 constructor name: APIGateway |
| 87 | +* The SDK v2 constructor name in all lower case: apigateway (primary format) |
| 88 | + |
| 89 | +Similarly, the `action` argument defined in the `AwsSdkCall` interface was advertised as being permitted in any of the following formats: |
| 90 | + |
| 91 | +* The API call name: GetRestApi |
| 92 | +* The API call name with a lower case starting letter: getRestApi (primary format) |
| 93 | + |
| 94 | +Migrating `AwsCustomResource` to SDKv3 meant that the permitted `service` and `action` values for SDKv2 needed to be accepted as well as new formats with respect to SDKv3. As a result, naming normalization was established as a way to convert the `service` and `action` arguments into the format expected for SDKv3 API calls. The normalization functions for `service` and `action` can be seen in the [sdk-info](./lib/sdk-info.ts) file and are named `normalizeServiceName` and `normalizeActionName`, respectively. To enable normalization of the `service` argument, the client package names map file from the `aws-sdk-js-codemod` repository is used and can be found [here](./lib/sdk-v2-to-v3.json). More specifically, this file is used to map SDKv2 `service` names to the equivalent SDKv3 `service` name. To enable normalization of the `action` argument a [sdk-v3-metadata](./lib/sdk-v3-metadata.json) file was extracted which contains a list of APIs that end in the word `Command` which allows us to disambiguate around these when generating the SDKv3 `action` name. Note that the [sdk-v3-metadata](./lib/sdk-v3-metadata.json) file also contains a mapping of `service` names into an IAM name allowing us to correctly identify the IAM prefix for each `service`. |
0 commit comments