Duplication of resource names in CDK

[LeonLuttenberger]

Is your idea related to a problem? Please describe.

In the definitions of L3 constructs in this repository, the resource ID is often manually appended as a prefix to IDs of newly created resources. An example can be seen sqs_lambda, but this is done consistently throughout the repository.

When CDK synth is applying logical IDs to CloudFormation resources, it already prefixes every resource with the IDs of it's parent construct (passed in the scope argument). For example, if a stack named Stack includes a custom construct with the ID SQSToLambda, and this custom construct in turn contains a basic SQS queue with the logical ID Queue, the queue will be generated with the logical ID SQSToLambdaQueue and given the name Stack-SQSToLambdaQueue<HASH_KEY>.

With the way resources are defined in this repository, the ID of the parent is prefixed twice. This leads to resource names such as DdkApplicationStack-ddksqslambdaddksqslambdafuncti-JOUkDEJv2g0e or DdkApplicationStack-ddksqslambdaddksqslambdaqueue84088044-kaHv5ZvGW3yy, where the substringsddksqslambda and ddksqslambda are duplicated. This is a common mistake in CDK code, and it leads to resource names becoming less descriptive, but also leaving less space for the actual description for what a resource does (since resource names in AWS tend to have small character limits).

Describe the solution you'd like

For the example of sqs_lambda, line 153 can simply be changed to id="Queue". This way, the generate name of the SQS Queue will be DdkApplicationStack-ddksqslambdaQueue<HASH_CODE>. Another good practice is to use capitalize words in the CDK resource names. The capitalization will be preserved during CDK synthesis, which will make the resource names more readable.

[malachi-constant]

I'm 100% for readability here especially if we tackle observability in the next major change as well. Reading dashboards with those names might look messy ;)

[jaidisido]

Good catch, thanks. Agreed that it should be addressed in the Typescript release

[malachi-constant]

@LeonLuttenberger I think we are already taking this approach in the typescript-conversion branch correct?

[LeonLuttenberger]

Yes, this should be fine in our TypeScript conversion.