Asynchronous processing (async/await) in a construct

[gabor-s]

❓ 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

[rrrix]

I wrap my "main" (entrypoint) in an async function, since I have some similar needs (I pre-fetch some things from Secrets Manager).

I don't use the out of the box directory structure (what comes with cdk init).

async function main() {
  const res = await getMyAsyncThing();
  const app = new App();
  new FooStack(App, 'fooStack');
  ...
}

main();

It works great for me!

[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 aws/aws-cdk-rfcs#167).

Closing for now.

[sblackstone]

@eladb I mostly agree with you here. But one important corner case is if you want to use node's crypto library. Those functions all use promises / callbacks.

[eladb]

Which functions?

[sblackstone]

@eladb nevermind, I erred. There are sync versions of what I thought was purely async.

Thanks!

[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]

Is it possible to use the new asset bundling API to run rollup within a docker container that has all the needed dependencies?

[twooster]

Unfortunately not, tryBundle is synchronous and expects a true/false response, not a Promise. :/ Hence the frustration -- everything is sync, even things that are practically speaking async. I think the only feasible path is to avoid the asset bundling api (and sadly miss out on the approved output directory and hashing/caching) and run async code ahead of the CDK calls and then pass in the resolved build output as a constructor parameter.

(Thank you for taking the time to respond. Sorry for the tone, just hit this wall after hours of digging into the codebase.)

[eladb]

Unfortunately not, tryBundle is synchronous and expects a true/false response, not a Promise. :/

You don't have to implement tryBundle. It can simply return false and then fall back to docker.