How the CDK manage names and logical ids is doing a lot of harm #10796
Labels
@aws-cdk/core
Related to core CDK functionality
closed-for-staleness
This issue was automatically closed because it hadn't received any attention in a while.
guidance
Question that needs advice or information.
response-requested
Waiting on additional info and feedback. Will move to "closing-soon" in 7 days.
❓ General Issue
Hi Folks,
I found the CDK extremely powerful but the way it manages names and logical ids by default is doing a lot of harm to this very promising development kit.
CFN stacks and all the medata in them (logical names, names,...) build an information system which is constantly used by humans.
On my side, I tend to look a lot to CFN stacks to understand the scope of ressources a service is related to.
It's also a single point of truth to find various resources and get their coordinates in order to perform checks or understand behaviours.
To me, I would say the CDK default behaviour is harming the ability to exploit this information system a lot.
The CDK is supposed to help us and it does but such a framework is not supposed to obfuscate information.
I understand the conflict thing but to me this is not up to the CDK to replace best practices and common sense in relation to naming conventions and how developpers want their resources to be named.
Plus, by default, some construct associated to the default naming policy tend to break the AWS console UI which is quite bad.
As an example, check the following screenshot:
It breaks consistently the UX in the cloudformation UI, the names are so long that the first column takes a lot of space and then the 2nd too. Finally the status of the resource is hard to catch rapidly. It's barely useable !
What is purpose of such default naming exactly ?
Hopefully some CDK ressources seem to support custome names but of for instance I did not find a way to have a clear name for the autoscaling scaling policy with a ridiculus long name "SupportBenchWorkerDevWorkerQueueServiceQueueProcessingFargateServiceTaskCountTargetCpuScaling124CEB17" which breaks the UI.
Additonnally, this naming thing is orthogonal to AWS SDK and API.
For instance when using boto3 or CFN you have most of the time to provide the right naming which forces you to build a consistent and well scoped naming space which is BTW part of any development practice in every language.
Could you imagine a language which will prevent you, by default, to name you own resources and then to constantly forces you to make a translation between your mental model and the language model, because developers would be to dumb to avoid naming conflict ?
And last but not least, to migrate existing stacks which had been carefully built with all the naming convention best practices is probably a very tedious task to do if fully possible.
It's too bad to have built such a powerful framework and to have spoiled it with such naming behaviour.
I hope it will change because I would like to fully embrace the CDK approach but this naming thing is almost a no go and a pain. I don't think it has to have to be that way.
Best.
Other information
The text was updated successfully, but these errors were encountered: