CDK code refactoring - best practices regarding constructs vs simple classes

[royby-cyberark]

Hi,
Regarding CDK code refactoring - sometimes I would like to create parent classes which will instantiate some child resources. usually I am create a construct - inheriting from Construct e.g. class Parent(Construct)

This has the benefit of adding the parent id to the children ids/names. but also this can cause resources to change logical id when moved around (and thus recreated).

On the other hand, I could use simple classes without inheriting Construct. this will have all the refactoring value, but without the logical id changes, but also without the naming hierarchy.

Are there any other reasons to favor one over the other?

Thank you for your help!

[royby-cyberark]

This is my take on the subject:
https://medium.com/cyberark-engineering/the-tale-of-aws-cdk-refactoring-logical-ids-and-lost-resources-fe9d91dfecd6

[spyoungtech]

Though, you can never use the same construct twice within the same scope with that approach. But a simple change that has the user of your class pass in an id you can use as a unique prefix for all the ids internal to the class.

class UsersData:
    def __init__(self, scope: Construct) -> None:

        Table(scope=scope, id='UsersTable', 
              partition_key=Attribute(name='user_id', type=AttributeType.STRING),
              removal_policy=RemovalPolicy.RETAIN)

        Table(scope=scope, id='UsersPermissions', 
              partition_key=Attribute(name='user_id', type=AttributeType.STRING),
              removal_policy=RemovalPolicy.RETAIN)

The problem shows up if the construct is used twice:

users_data = UsersData(self)
more_users_data = UsersData(self)  # fails due to ID collision

Simple fix is to require the user to pass in an ID you can use as a prefix.

-     def __init__(self, scope: Construct) -> None:
+     def __init__(self, scope: Construct, id: str) -> None:
-        Table(scope=scope, id='UsersTable', 
+        Table(scope=scope, id=f'{id}UsersTable', 
               partition_key=Attribute(name='user_id', type=AttributeType.STRING),
               removal_policy=RemovalPolicy.RETAIN)
 
-         Table(scope=scope, id='UsersPermissions',
+         Table(scope=scope, id=f'{id}UsersPermissions', 
               partition_key=Attribute(name='user_id', type=AttributeType.STRING),
               removal_policy=RemovalPolicy.RETAIN)

With that change, it works more closely like a normal construct. Technically, there's still a chance for id collision, but the risk is greatly minimized and you can use the "construct" multiple times in the same scope:

users_data = UsersData(self, 'data1')
more_users_data = UsersData(self, 'data2')  # works now!

[github-actions[bot]]

Hello! Reopening this discussion to make it searchable.