Async / Promises in Constructs

[skorfmann]

While building the equivalent of the EcrAssets package for the Terraform CDK, I stumble upon the lack of async / Promises support for generating a hash of the folder content as a trigger for the Docker image build.

A quick search in the AWS CDK repo revealed, that others have tried this as well, but there's not a way to do it at the moment. See aws/aws-cdk#8156 and aws/aws-cdk#8273

@eladb mentioned in aws/aws-cdk#8156 (comment) that "it's not supported in the current CDK programming model". Is this primarily due to implementations in the AWS CDK and the Constructs package could support this in theory? Or are there other reasons which are blocking this?

[skorfmann]

Ok, that's how the AWS CDK team solved my particular issue: https://github.com/aws/aws-cdk/blob/1755cf274b4da446272f109b55b20680beb34fe7/packages/%40aws-cdk/core/lib/fs/fingerprint.ts#L23 - We should probably borrow from that fs folder for cdktf

Nevertheless, still would be great to enable async operations somehow.

[eladb]

@skorfmann see my response here: aws/aws-cdk#8273 (comment)

[eladb]

My recommendation is to avoid this for now given it creates a potential opportunity for abuse

[skorfmann]

@skorfmann see my response here: aws/aws-cdk#8273 (comment)

Thanks for the context. To some extent this contradicts what's written in the RFC, since the JS AWS SDK is completely asynchronous:

The initial implementation will not synthesize data sources. The practitioner should be able to use the language of their choice and a cloud provider’s SDK to make API calls and retrieve identifiers and metadata, similar to how data sources are implemented in Terraform.

While I see the point of having deterministic results for the synthesized configuration, I'm not entirely convinced that this holds true for Terraform. I believe it's quite common in Terraform to perform dynamic actions based on user input or data sources. And then it's really just a question if the Terraform engine expands the dynamic resources, or the CDK at compile time. I'd prefer the latter, since it allows more options for pulling in data and way better error handling.

My recommendation is to avoid this for now given it creates a potential opportunity for abuse

There's an ongoing PR to add Data Sources. From that point of view, we should be ok for now. Personally, I think we should keep this on the roadmap though.

[eladb]

You can use child_process.execSync to execute commands from the initializer chain and also you can use the trick we use in cdk8s to perform http requests synchronously (by execSync into a child node process).

[skorfmann]

You can use child_process.execSync to execute commands from the initializer chain and also you can use the trick we use in cdk8s to perform http requests synchronously (by execSync into a child node process).

Cool, thanks for the hint 👍 - I'll check it out

[anubhavmishra]

@skorfmann can we close this issue?

[skorfmann]

@skorfmann can we close this issue?

Yeah, I think for now this can be closed.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days. This helps our maintainers find and focus on the active issues. If you've found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.