I've been using AWS CDK since the first preview versions and experienced the same mind blown feeling. It really changes the way you think about IaC (Infrastruct

I've been using AWS CDK since the first preview versions and experienced the same mind blown feeling. It really changes the way you think about IaC (Infrastructure as Code) when cloud resources are programmable and abstractable in TypeScript. This is particularly true when you develop serverless applications that are tightly integrated with cloud services (API Gateway, Lambda, etc). I've recently started to merge IaC code with runtime code, so that Lambda functions and AWS CDK projects share the same dependencies and the same package.json. I think Pulumi does something similar, although I'm not familiar with it. It makes development one step simpler, because you only have a single set of dependencies to worry about in a project. Esbuild takes care of only deploying the code you actually need to the Lambda functions. The next step I hope to see is TypeScript type support for AWS Step Functions. Currently there's no type checking for the input and output objects of Step Function States, or for the various selectors you can specify for them. With proper typings, AWS CDK could throw deploy-time errors when Step Functions are badly configured or don't match the input/output types of related Lambda functions. Actually, you might see the problems already while editing the project in Visual Studio Code. The future direction here is that you can implement fully featured cloud applications, including runtime code, with very little boilerplate code, just by defining data structures, essential business logic and high-level cloud resources. AWS CDK will take care of all the details by default.