I'm currently working on a deployment pipeline for a microservice that uses AWS Lambda along with the AWS Cloud Development Kit (CDK). My Lambda function has some large dependencies—around 80MB—which I've moved to a Lambda Layer, while keeping smaller runtime dependencies directly within the function.
I've organized my `package.json` where the `dependencies` section includes smaller runtime libraries like `hono`, `joi`, and `aws-sdk`, while `devDependencies` contains tools for building and CDK like `typescript`, `aws-cdk-lib`, and `tsx`.
However, I feel like my CDK construct is kind of messy and not very efficient. For bundling, I'm currently using a complex setup with bash commands in an array. I feel like I'm straying from best practices. Here are some of my specific questions:
1. Is this the standard approach to utilize layers with CDK? It feels less organized compared to other CDK implementations.
2. Why isn't CDK handling TypeScript compilation and pruning of devDependencies by itself? It seems counterintuitive that I have to resort to bash scripts.
3. I can't use `NodejsFunction` with `esbuild` due to constraints in my project. Are there any better alternatives available?
Overall, my current flow involves running `npm ci`, building the TypeScript with `tsc`, pruning devDependencies, removing unnecessary Layer modules, and then copying the output to the required directory.
6 Answers
By the way, AWS has been experiencing a significant outage that’s been going on for about 12 hours now. Just thought I'd let you know!
You might want to check if you have `esbuild` added as a dev dependency in your CDK project. Here's a good example that shows how it can do the heavy lifting without manual scripts—see [this GitHub link](https://github.com/aws-samples/serverless-patterns/blob/main/lambda-dynamodb-cdk/cdk/lib/cdk-stack.ts) for lines 20–29. The `NodejsFunction` construct takes care of bundling and uploading for you, keeping things simple!
Using layers can feel a bit tricky, but it’s usually straightforward if you refer to the CDK documentation. It simplifies setting up AWS Lambda functions. You can find some helpful examples [here](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_lambda_nodejs-readme.html).
I use `esbuild` to manage my TypeScript and dependencies. It automatically packages everything, so you only get what you need in the bundle. Here's a bit of how I set it up:
```javascript
const lambda = new NodejsFunction(this, 'MyLambda', {
bundling: {
sourceMap: true,
minify: true,
},
runtime: Runtime.NODEJS_22_X,
entry: 'lambda/processor-lambda.ts',
handler: 'handler',
environment: {
NODE_OPTIONS: '--enable-source-maps',
// other env vars
}
});
```
Sadly, some modules I'm working with aren't compatible with `esbuild`. I'm constrained in that regard.
I usually steer clear of layers because they complicate the build and deploy process. Unless you’re planning to reuse your code across multiple functions, it might just add unnecessary overhead.
If using `esbuild` isn't an option for you, consider my project `cdk-turbo-layers` to help package your layers efficiently. It automates the layer packaging process, speeding up deployment and reducing manual overhead. Here's a quick snippet:
```javascript
const packager = new NodejsDependencyPackager(this, 'Packager', {
runtime: lambda.Runtime.NODEJS_20_X,
type: DependencyPackagerType.LAMBDA,
});
const layer = packager.layerFromPackageJson('function dependencies', 'lambda-src');
new Function(this, 'Function', {
handler: 'index.handler',
code: lambda.Code.fromAsset('lambda-src'),
layers: [layer],
});
```
Totally agree! There's really no need to manually manage the bundling process when the modules are designed to handle that for you.