Asynchronous processing (async/await) in a construct

❓ General Issue

The Question

Is it possible to do asynchronous processing in a Construct? Is there anything in CDK that will wait for a promise to resolve? It seems that everything is synchronous.
I need to resolve a string value to a path, but it could take some time so implemented it asynchronously.

Options considered:

Aspects

The visit method is synchronous.

Tokens

The resolve method is synchronous.

Create the app asynchronously

async function createApp(): Promise<App> {
    const result = await asyncProcessing();
    const app: App = new App();
    // pass result to every stack, bit ugly
    return app;
}

Context

The same as before, but put result into the context, so don’t have to pass it to every stack/construct. Honestly, I don’t really like this solution, because the construct is reaching out to some known location to get a value. Like process.env calls that are scattered throughout the code.

Is there any support in CDK for asynchronous processing? Or is it an anti-pattern and I’m doing the wrong way?

Environment

• CDK CLI Version: 1.39.0
• Module Version:
• OS: Windows 10
• Language: TypeScript

Other information

[twooster]

Strong disagree here, and a bit annoyed. Sorry.

I need/want a custom asset bundler for Cloudwatch Synthetic event lambdas (due to the directory layout requirements if you have more than a single .js file among other reasons). I could do all of this with rollup in an async function inside of the context of my CDK code, but I will instead be forced to run child_process.spawnSync (as per @aws-cdk/aws-lambda-nodejs’s LocalBuilder) or similar such inanity.

It’s disingenuous to claim to be protecting users from themselves maybe possibly doing something that could lead to non-deterministic behavior as a means of justifying only allowing sync-flavored methods. The architecture of aws-cdk doesn’t permit async, but that’s a limitation of its constructor-based design, not an imperative.

[eladb]

We currently do not support this and in general we consider this an anti-pattern. One of the tenets of CDK apps is that given the same source they will always produce the same output (same as a compiler). If you need to perform async operations, it means you are going to the network to consult with an external entity, which by definition means you lose determinism.

File system operations can be done synchronously in node.js, so consulting your local disk is “ok”, but bear in mind that this still means that you may end up with non-deterministic outputs which breaks some core assumptions of the framework and considered a bad practice in the operational sense.

One direction we are considering is to open up the context provider framework (see https://github.com/aws/aws-cdk-rfcs/pull/167).

Closing for now.