DEV Community: Sebastian Hesse

Migrating a CDK Construct to projen and jsii

Sebastian Hesse — Mon, 01 Mar 2021 09:00:00 +0000

CDK constructs are a great way to combine best practices and simplify your infrastructure code. Have you ever written your own CDK construct? Writing a construct is easy using the CDK CLI. But soon you’ll discover the hard parts: Keeping all dependencies updated; Aligning the CDK dependency versions to not have version conflicts; And publishing your CDK construct to multiple repositories. projen makes the CDK construct setup and maintenance a lot easier. And jsii helps to release your TypeScript CDK construct to Java, Python and C#. Here is a short tutorial about migrating a CDK construct to projen and jsii.

I have provided a beginner’s step-by-step guide about getting started with projen and jsii. This will help you exploring typical options for projen and explains the process of publishing your CDK Construct to repositories like NPM, Maven, PyPi, and NuGet using jsii. I recommend to read it if you have no prior experience with projen or jsii.

About projen and jsii

projen is a tool to write your project configuration using code instead of managing it yourself. It was created to help you writing CDK constructs. You only define your project configuration in a .projenrc.js file and it will generate your project files for you. This includes a package.json and other configuration files for eslint or GitHub Actions. It is designed to automate all the boring project setup steps.

jsii is the technology behind the AWS CDK that allows you to write CDK Constructs in TypeScript/JavaScript and compile them to other languages like Java or Python. There’s a good AWS blog post about how it works.

Setup Your Construct Project

Let’s start to migrate your existing CDK Construct to projen. You have probably created your CDK construct using the following cdk command:

cd my-cdk-construct
cdk init lib --language=typescript

That command creates various folders and files with pre-defined defaults writing a CDK construct using TypeScript. For example, it initializes your project with a lib and test folder as well as an example construct file and a related test file. Finally, you can run your tests using Jest with npm run test. This is the basis of the next steps, even though you might have added further lib files, tests or tools like ESLint or similar.

Please note that you can only use projen and jsii with TypeScript/JavaScript as the source language at the moment. This means, you can not create a CDK construct in Java and publish it to NPM.

Migrating Your CDK Construct to projen

💡 Before you start migrating your CDK construct to projen, you might want to open this blog post about converting your CDK construct to using projen by Matthew Bonig in another browser tab. His article also covers some interesting facts and small errors he has experienced in the process, so they might help you as well.

Before you execute any command, make sure you have a clean Git status. This ensures that you can easily revert any undesired changes.

The following commands will initialize your project with projen. It will create a file called .projenrc.js containing a default projen configuration. Then it will automatically execute this file for you to generate further files and folders based on your projen configuration:

cd my-cdk-construct
npx projen new awscdk-construct

After executing the commands, you’ll see lots of changes in your Git status. For example, projen expects source files in src whereas a CDK construct initialized via the CDK CLI expects them to live in lib. Also, there will be a folder called .projen containing configuration files for projen. You don’t need to look into all of the new files immediately. projen is managing the contents of files like GitHub Actions or TypeScript configurations based on the settings you define in .projenrc.js.

Updating Your Project Files with projen

After migrating your CDK construct to projen, you should always follow this process to update project files generated by projen:

Make according changes in .projenrc.js.
Run npx projen and projen will synthesize the changes to all project files. 💡 Hint: create an alias like pj in your command line to avoid typing npx projen over and over again.
Never manually edit the generated files because projen will overwrite them the next time!

If you have used tools like eslint or Dependabot before, you’ll probably see changes in their related files as well. If you don’t like the defaults, you can always change the settings in .projenrc.js. However, you’ll probably don’t have to change that much since projen is applying common settings for eslint. I only noticed two changes compared to my settings : include an uppercase ‘i’ (= I) in interface names and make its properties readonly. Everything else was just related to some minor style adjustments.

💡 Since I don’t know all varieties of CDK construct setups, you might run into other errors after adding projen. If you have any problems you can’t solve by yourself, feel free to reach out to me or send your question to the CDK developers Slack.

Important General Settings

Now it’s a good time to have a look at the most important settings you can set in .projenrc.js. I’ll outline them below and explain them in case it’s not too obvious.

Setting	Description
projectType	Define if this project is a library or app. For a library (i.e. CDK construct), you should use `ProjectType.LIB`.
packageManager	Define which package manager you want to use, e.g. Yarn or NPM. Set the value like `NodePackageManager.NPM`.
cdkVersion	With this property you are defining the CDK version you want to use for all CDK dependencies. Due to the nature of CDK, it’s important to align the numbers.
cdkDependencies	Enter all the CDK dependencies that you are using in your construct. You probably had them defined in your package.json file before but now you need to add them here. Add them like `['@aws-cdk/core', '...']`. Since you specify the CDK version with `cdkVersion`, you don’t need to set it here.
bundledDeps	List of dependencies you want to bundle with your construct. This might be necessary in case you use some constructs like `NodejsFunction` for a Lambda function. It will build your Lambda function’s code only when the Lambda function is used in a CDK stack. And then those dependencies need to be available.
deps	Any other regular dependencies that your construct is using.
peerDeps	A list of peer dependencies. `projen` will automatically add all `@aws-cdk` dependencies to the list of peer dependencies, so you don’t need to define them here. But you can add any other dependencies here that you’d like to have in the resulting `peerDependencies` of the `package.json` file.
packageName	By default, `projen` will take the `name` property as the name in `package.json`. However, it might be necessary to overwrite it here.
gitignore, npmignore	Should be self explanatory. You can define a list of strings matching files or folders you’d like to ignore for Git or NPM.

Important: Don’t forget to run npx projen each time you make a change in .projenrc.js. Otherwise projen won’t synthesize the config changes to your project files.

Release Settings

You have to consider that by default projen assumes you want to publish your CDK construct to NPM. Hence, it sets up GitHub Actions that perform the relevant tasks for you, like bundling, running the tests and releasing the artifact. If you want to skip this for now, consider adjusting the following settings:

Setting	Description
releaseBranches	A list of branch names. The default is `['main']` but you can adjust it to whatever branches you need. If you set this to an empty array, then you can only trigger a release by manually starting the release workflow (in case you enabled to add a release workflow, see below).
releaseEveryCommit	If set to `true` and a commit is added on any of the branches defined in `releaseBranches`, then a release is triggered.
releaseSchedule	Optional: cron expression to regularly release a new version.
releaseToNpm	If a new version should be released to NPM using GitHub Actions.
releaseWorkflow	If you want to have a release workflow using GitHub Actions.

Again, don’t forget to run npx projen to update your project files after changing the projen settings in .projenrc.js.

Location of Lambda Function Code

In case you are creating a Lambda function in your CDK construct, you might wonder where you should put your Lambda function code and how you bundle it. When using projen, I’d say a good approach is to keep all the Lambda function code in a subfolder next to your CDK construct source files. For example, the code could go into src/lambda. This ensures that projen picks up the files and includes them in the artifact that’s being released to NPM. You can read my other blog post if you want to know more ways about how to bundle your Lambda function code in a CDK construct.

Building Your Construct

Now that you have finally adjusted the necessary projen settings and fixed any code or linting issues, you can verify that your code compiles. You can use commands like npm run build or npm run test to verify your code. (Use Yarn instead if you kept projen‘s default setting of packageManager) Is your code compiling? Great! If not, did you forget anything or did I miss to cover anything here? Let me know about it!

After a green build, you are ready to commit your changes and push them to your remote Git repository. Then, the GitHub actions configured under .github/actions will trigger and build (+ release) your CDK construct 🚀

Custom Build or Workflow Steps

Before migrating your CDK construct to projen, you probably had some custom scripts or commands in your project. For example, you prepared certain things for a Lambda function or your CDK construct in general. With projen you can add custom build and workflow steps as well. Here is how you can do it in .projenrc.js:

const project = new AwsCdkConstructLibrary({...});

// add a build step:
project.buildTask.exec('echo "Hello World"');

// add a job to the GitHub Action file of release.yml:
project.releaseWorkflow.addJobs({
  example: {
    name: 'Example Job',
    'runs-on': 'ubuntu-latest',
    steps: [{...}],
  },
});

As soon as update the project files by running npx projen again, you’ll see changes in .projen/tasks.json and .github/actions/release.yml.

Publishing to Multiple Repositories Using jsii

After you have finally migrated your code, it’s time to add some magic to your CDK construct. The magic comes by a combination of projen and jsii. Their biggest advantage is that you can make your CDK construct available not only to NPM but also Maven, PyPi and NuGet by just setting a few settings.

As described above, projen provides a few release settings. Use them to publish your CDK construct to NPM. If you want to publish your CDK construct to Maven, PyPi or NuGet, then consider the following settings:

Setting	Repository	Description
publishToMaven	Maven	Allows you to configure the Java package, group id and artifact id.
publishToPypi	PyPi	Allows you to configure the dist name and module.
publishToNuget	NuGet	Allows you to configure the namespace and package id.

Enabling these settings (and running npx projen again 😉) will create appropriate steps in the release.yml GitHub Action. You can find detailed steps for each repository in my guide about creating a CDK construct using projen and jsii on GitHub. Besides that, you don’t need to do anything. Just commit your changes and wait for the magic to happen!

A successful release using projen and jsii. Example taken from projen-test.

Conclusion

I hope you were successful in migrating your existing CDK construct to projen and jsii. In my opinion it offers a really good way to manage your project and hide quite a few complicated steps. Also, shipping to various repositories works like a charm!

Are you running into any errors? Comment below and let me see if I can help you 😊

The post Migrating a CDK Construct to projen and jsii was first published on Sebastian Hesse - Software Engineer.

Using Spring Boot On AWS Lambda: Clever or Dumb?

Sebastian Hesse — Sun, 14 Feb 2021 13:00:00 +0000

I often notice people wondering if and how it’s possible to run Spring Boot on AWS Lambda Functions. I understand this because I know developers in the Java ecosystem often use the Spring Framework. And since more and more people built Lambda functions using Java, the question will be asked at some point. It’s definitely possible to run Spring Boot on AWS Lambda. However, if you think about it a second time, you’ll find many reasons why it is a bad idea. This blog post discusses the advantages and disadvantages of running Spring Boot on AWS Lambda on a conceptual level. And in case I won’t convince you, I’ll at least provide you some hints to overcome the disadvantages.

Are you using Java or even Spring (Boot) on AWS Lambda? I have used it in production systems and I believe it’s good for certain use cases like background data processing. What is your use case? Do you try to overcome the disadvantages and if so, how? Just add a comment below or mention me on Twitter 👍

Some Context Around Spring Boot And AWS Lambda

As you all probably know (if not, then read here), AWS Lambda and similar Function-as-a-Service (FaaS) solutions let you run code in the cloud without managing any of the underlying infrastructure. This enables a cloud provider to better scale your code because these functions are a small enough to be started on demand. Although Java is one of the supported languages with a slower initial start time (= cold start), it can still be a good choice for AWS Lambda because of its big ecosystem that grew over all the years.

For example, the Spring Framework is one of the most popular Java frameworks. It collects best practices working with different things like a database and HTTP. Eventually Spring Boot made it even simpler to connect the different Spring modules together. A typical use case for Spring Boot is to build a microservice that can handle HTTP requests. You just define a @Controller , give it a @RequestMapping and have your first endpoint ready that can react to an HTTP request (read this blog post as an example).

Connecting AWS Lambda And Spring Boot

Unfortunately this setup won’t work out of the box if you’re running this code on AWS Lambda. The reason is that AWS Lambda is using an event-based mechanism. An event can consist of any kind of data that is serializable. However, you won’t be able to receive HTTP requests from within your Lambda function. (Of course you can make HTTP requests to other services but not the other way around). This is the reason why you need a service or application in front of your AWS Lambda function. Such a service can receive HTTP requests and forward them to your Lambda function. A typical example is an AWS API Gateway. But you can also use an AWS Application Load Balancer. These services keep the HTTP connection open until your Lambda function responds to the HTTP event. Without this setup you won’t receive any HTTP events in your Lambda function.

In order to start using Spring Boot on AWS Lambda, I suggest you to checkout the different helpers in aws-serverless-java-container. This is a collection of Java classes that help you using typical Java frameworks on AWS Lambda, including Spring. They already provide you with the necessary glue code to connect the AWS Lambda handler with Spring Boot. There are also other (but similar) ways to ingrate the Spring Framework like using Spring Cloud Functions on AWS Lambda. In the end, the architecture looks similar to this:

Architecture how an HTTP request is received as an event from API Gateway to Spring Boot in your Lambda function.

Advantages

Let’s discuss the advantages of this approach because there are definitely a few. First, you can setup an API Gateway to forward all HTTP requests as events using a proxy integration with AWS Lambda. This basically enables you to configure a wildcard path in API Gateway and lets your Spring Boot app handle all the internal routing. Using this approach, you and your team can continue using Spring Boot like you’re used to. Second, as soon as one Lambda function instance has initialized the Spring Boot container, this function will respond in a consistent way. The performance is as expected from Java, at least that’s my experience with Java Lambda functions.

However, the most obvious advantage is that you don’t have to manage the underlying instances with AWS Lambda. But this advantage has a catch: You need to ensure you are not storing any session data (or similar) inside your Spring Boot app. Remember that you should keep Lambda functions stateless, otherwise scaling becomes harder.

Disadvantages

You might have recognized already that using API Gateway + AWS Lambda + Spring Boot is duplicating responsibilities. In the world before Serverless you would have used Spring Boot alone to handle HTTP requests and implement your business logic. Now the combination of API Gateway and AWS Lambda is replacing it. Even more than that, it enables you to have better scalability because of this separation of concerns from an operational aspect. This means you can put a big question mark on the idea of running Spring Boot inside AWS Lambda.

But not only duplicating responsibilities is a bad sign. Also the fact that you add unnecessary complexity to integrate Spring Boot with AWS Lambda should make you think twice. In the end, all these wrapper and helper classes introduce more potential for bugs. And together with Spring Boot they also have a bad effect on the cold start of your Lambda functions of course. Apart from that, Spring Boot own it’s own is even too slow to start quickly like it’s expected from Lambda functions. This means, you’ll have massive spikes in your response times when a new Lambda function instance is started.

Although not worrying about the instances of your Lambda function sounds appealing, you have to remember that you can not control how many you’ll have. This can have negative consequences if you’re e.g. making requests to an SQL database in direct response to external events. You might run out of database connections quickly if a spike hits your Lambda function because AWS Lambda spins up more and more instances.

My Personal Opinion And Experience

I (and many other Serverless developers) recommend to keep AWS Lambda functions simple and small. If you follow this recommendation, then your functions are a lot easier to scale. If you instead build another monolith using Spring Boot on top of AWS Lambda, then you are doing it wrong. Keep that in mind while developing AWS Lambda functions with Java but especially if you include Spring as well.

Having said that, I have successfully used Spring in Java Lambda functions in previous projects. I enjoyed running them in the background doing some data processing. However, I’m not convinced that they are a good choice for “customer facing” endpoints like a REST API. The only exception is if you keep a minimum of Lambda instances running. But then you can question if AWS Lambda is the right choice for your Spring Boot app. In such a case I’d rather suggest you to use traditional EC2 instances or ECS.

If you still want to use Sprint Boot on AWS Lambda, then you should consider some recent developments. For example, you might have heard of GraalVM or Quarkus. You can use it to run Java native images on AWS Lambda by providing a custom runtime. Also, Spring is adding support for GraalVM native images. I can recommend looking into the Slides of Vadym’s talk “Adopting Java for the Serverless world” that goes into more detail.

The post Using Spring Boot On AWS Lambda: Clever or Dumb? was first published on Sebastian Hesse - Software Engineer.

Serverless Sending and Receiving E-Mails, the CDK Way

Sebastian Hesse — Sun, 31 Jan 2021 15:00:00 +0000

Serverless sending and receiving e-mails using AWS is not fun in my opinion. AWS offers Simple Email Service (SES) to achieve this. But the UI and also Infrastructure as Code (IaC) support is lacking. You often need to manually change settings which is error prone. When I recently built another landing page for myself, I was repeating the same steps as for the previous page. It bothered me why there’s no easy automation that’s doing it for me. This is what I’m presenting to you today: My first AWS CDK Constructs to send and receive e-mails.

You can find the source code of the AWS CDK Constructs in the ses-email-forwarding GitHub repository. Besides that, I also made ses-verify-identities available as separate AWS CDK Constructs.

Setup Steps With AWS SES

Have you ever built your own landing page with its own domain? Or have you ever wanted to use another alias for receiving e-mails? Or did you just want to use an e-mail address for a domain you own without the hassle of setting up your own mail server and instead forward the mails to your existing inbox? If yes, I have some great news for you! 😊

Initially, I have used a library called aws-lambda-ses-forwarder for serverless sending and receiving e-mails. I always had to follow these manual steps:

Setup AWS SES and verify my domain.
Configure receipt rules for the different e-mail addresses.
Then setup a Lambda function SES Action that forwards all my e-mails from SES to a Gmail address.
Configure SMTP for AWS SES and setup Gmail to send e-mails with my verified domain.

My new AWS CDK constructs below automate the first three setup steps for AWS SES. They even allow you to automatically verify your e-mail addresses or domains within SES (if you’re using Route53). Just deploy the constructs in your AWS CDK stack and you’re ready to go. You only need to create SMTP credentials for AWS SES and setup your settings with Gmail (or other providers). Let’s see how it’s working ⬇

AWS CDK Constructs to the Rescue

The best way to show how it’s working is by showing you a few lines of code:

new EmailForwardingRuleSet(this, 'EmailForwardingRuleSet', {
  enableRuleSet: true,
  emailForwardingProps: [{
    domainName: 'example.org',
    verifyDomain: true,
    fromPrefix: 'noreply',
    emailMappings: [{
      receivePrefix: 'hello',
      targetEmails: ['whatever+hello@provider.com']
    }]
  }]
});

The code is using the EmailForwardingRuleSet construct to configure everything. Let me quickly the most important things:

You can configure to automatically enable the rule set because you can only have on active rule set in AWS SES.
You define e-mail forwarding rules by specifying your domain name and the e-mail mappings. E-mail mappings define a receivePrefix which is your e-mail alias and a list of targetEmails. All e-mails to your alias/prefix are forwarded to these target e-mails. The forwarded e-mails have a prefix of noreply@example.org.
If the domain is managed by Route53, then you can automatically verify the domain. This setting will configure some custom resources to validate the domains.

That’s it already. You can further extend the configuration of course. For example, you can add more e-mail mappings for various aliases/prefixes. Or you can add another domain with individual e-mail mappings. It’s up to you 👍

Deploy Your AWS CDK Stack

Now you just need to put everything into an AWS CDK stack. Before you start, initialize a new CDK stack and install my CDK constructs:

cdk init app --language=typescript
npm i -D @seeebiii/ses-email-forwarding

Then, create a new file that contains your stack. It can look similar to the following example:

const app = new cdk.App();

class EmailForwardingSetupStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    new EmailForwardingRuleSet(this, 'EmailForwardingRuleSet', {
      // define your config here
    });
  }
}

new EmailForwardingSetupStack(app, 'EmailForwardingSetupStack', {
  env: {
    account: '<account-id>',
    region: '<region>'
  }
});

Finally, you use the cdk deploy command to deploy the stack. Everything else like verifying your domains and setting up SES will be done for you. Now you can start with serverless sending and receiving e-mails!

In the end, you’ll have this architecture for serverless receiving e-mails using AWS SES:

All 1.) incoming e-mails are handled by SES. SES will 2.) move them to S3 and afterwards 3.) invokes a Lambda function. This Lambda function 4.) loads the e-mail from S3 and 5.) forwards it to either Gmail or another target e-mail address. In case you are interested, I have written another blog post about how you can include AWS Lambda functions inside a CDK construct.

Sending E-Mails with AWS SES

Unfortunately this is the remaining step that can’t be automated. Once the above CDK stack is deployed to your AWS Account, you need to create SMTP credentials in AWS SES. These credentials allow you to send e-mails from any e-mail application or provider like Gmail. However, this will only work if you have verified your sender domain in AWS SES. Otherwise your e-mails will only be sent to verified e-mail addresses to avoid that you’re sending spam through AWS SES. If you would like to verify the target e-mail addresses with the CDK construct, just use the setting verifyTargetEmailAddresses.

Conclusion

I’ve learned a lot on the way of building my first AWS CDK construct! On tricky part was to bundle a Lambda function inside the AWS CDK Construct as mentioned above. I’m really happy with the result because I can easily extend the settings for new landing pages or other email aliases. What do you think about my solution? Let me know in the comments below or mention me on Twitter!

The post Serverless Sending and Receiving E-Mails, the CDK Way was first published on Sebastian Hesse - Software Engineer.

5 Ways To Bundle a Lambda Function Within an AWS CDK Construct

Sebastian Hesse — Sat, 16 Jan 2021 12:32:38 +0000

Have you ever tried to publish a CDK construct that was using a Lambda function, for example to create a custom resource or provide a REST API endpoint? It’s relatively easy to publish your construct if your Lambda function is just using the AWS SDK. But it gets more complicated as soon as other dependencies are involved as well. This post will present you five different ways to bundle your Lambda function within a CDK construct and tells you about the advantages and disadvantages of each option.

Problem Context

Recently I started digging more into the AWS CDK world and wanted to build a simple single page application. I had some special requirement for which I couldn’t find an existing CDK construct available in TypeScript. So I thought let’s create it myself and publish it later to NPM. I wanted to include a Lambda function in this CDK construct that was using an external dependency apart from the AWS SDK. The problem is that if you require other dependencies in an AWS Lambda function, you need to bundle them with your function (the AWS SDK is always available for Node.js runtimes). This means, you have to create an artifact that includes all required dependencies. However, I wanted to avoid that my resulting CDK construct package gets too big. I had some ideas in my mind but also asked CDK experts on Twitter for their opinion and experiences. Below are the results of my ideas and their suggestions!

// Detect dark theme var iframe = document.getElementById('tweet-1348716172649361408-996'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1348716172649361408&theme=dark" }

You have another idea how to include a Lambda function in a CDK construct? Please comment below ⬇️ or let me know via Twitter @seeebiii. If you’re curious about developing AWS Lambda functions in general, I can recommend you my article about best practices developing AWS Lambda functions.

Inline Code in CDK Construct

The easiest solution is to write some inline code within the CDK code. It usually looks like this when using the Function construct from the @aws-cdk/aws-lambda package:

new Function(this, 'MyFunction', {
  handler: 'index.handler',
  code: Code.fromInline(`
    exports.handler = async (event) => {
      console.log('event: ', event)
    };
  `),
  runtime: Runtime.NODEJS_12_X
});

This code will create a Lambda function with a very basic implementation. You can of course extend it further. However, you are a bit limited in terms of which dependencies you can include. For example, you can only refer to external dependencies like the AWS SDK and regular Node.js modules like path of fs. Also, this approach only works for runtimes that interpret text files, like Python or Node.js. It does not work for languages like Java.

Advantages:

Quick and easy way to write a Lambda function
No extra bundle steps necessary

Disadvantages

You are very limited what your function can do
No IDE support while writing your code
No testing possible, only manual tests

Separate File(s) in CDK Construct

Instead of providing inline code, you can also move your Lambda function code outside of the CDK code into a separate file. Then, you just link to your file from the CDK construct your using. For example:

new Function(this, 'MyFunction', {
  runtime: Runtime.NODEJS_12_X,
  handler: 'index.handler',
  code: Code.fromAsset(`${path.resolve(__dirname)}/lambda`)
});

The code property is referencing an external asset which points to the file of your Lambda function. It assumes the following folder structure:

root/
 - my-stack.js
 - lambda/
   - index.js

When deploying a stack with this function code, the CDK will simply take the index file of your Lambda function and use it as your Lambda function’s code. You can do something similar using other runtimes like Java or Python. Just reference the appropriate artifact like a JAR or Python file. Although this approach is much more preferred than writing inline code, it still has the drawback that you can not simply include other dependencies apart from the AWS SDK, at least for Node.js. You could of course zip your index.js file together with your node_modules folder and use that as your artifact. However, this approach is not recommended because it unnecessarily slows down your Lambda function due to a bigger artifact size. You’re just carrying around code which you’re not using.

Advantages

Keep CDK stack code and Lambda function code separated
You can test your Lambda function’s code using automated tests
IDE support while writing your Lambda function’s code

Disadvantages

External dependencies (apart from AWS SDK) not supported

Bundle Lambda Function Before Publishing

If you want to use other external dependencies, you need to make sure that those dependencies are available when your Lambda function is executed. Therefore, the next logical step is to bundle your Lambda function’s code and generate a code artifact with all the dependencies included. This artifact is used by your CDK construct and in the end used by the users of your construct. In your CDK construct you still use the same Function definition as above where you include the code asset. However, you have to make sure to bundle your code before you publish your CDK construct to any registry like NPM. For example, if you’re writing a TypeScript Lambda function, you can use esbuild (or webpack or similar) to compile and bundle it to “native” Node.js code that your Lambda function understands:

esbuild lambda/index.ts --bundle --platform=node --target=node12 --external:aws-sdk --outfile=lambda/build/index.js

This command creates an index.js file with all dependencies included, except the AWS SDK since this is already provided by the Lambda runtime. If you want to speed up your Lambda function even more, you can append --minify to use minification and reduce the output size. Here the output file is created under lambda/build, so take care to adjust the Function definition. For example:

new Function(this, 'MyFunction', {
  runtime: Runtime.NODEJS_12_X,
  handler: 'index.handler',
  code: Code.fromAsset(`${path.resolve(__dirname)}/lambda/build`)
});

In order to include the Lambda function’s code in your published CDK construct, consider the following:

Make sure the lambda/build folder is not ignored by NPM (this is usually configured in .npmignore)
Before publishing the construct, you have to bundle the Lambda function first – otherwise your published construct is missing the code for your Lambda function

Advantages

Everything from the previous section about having separate files
You don’t make any assumptions about the environment of the users that use your construct (will be important in the following sections)
You throw out all unnecessary code by only bundling the relevant code and maybe even minifying it

Disadvantages

It takes another build step and slightly increases the size of your CDK construct

Bundle Lambda Function Before Deploying

Instead of bundling the code before publishing your CDK construct, you can also bundle your Lambda function code before the construct is deployed to AWS. The AWS CDK provides a construct for Node.js Lambda functions called NodejsFunction from the @aws-cdk/aws-lambda-nodejs package. This construct will build the Lambda function as soon as your CDK construct is deployed within a stack. The NodejsFunction construct is using esbuild to do that or a Docker container if esbuild is not available (read more about it in the documentation). Using it in your construct is similar to how you define a regular Function – however, it already defines some useful defaults. An example definition can look like this:

new NodejsFunction(this, 'MyFunction', {
  entry: `${path.resolve(__dirname)}/lambda/index.js`
});

As you can see, it’s pretty simple and short. Unfortunately the big disadvantage is that you make assumptions about the environment where your construct is deployed. If they don’t have esbuild or Docker available, it won’t work. Therefore it only makes sense to use NodejsFunction in an constructs where you control the environment or if you let your users know about this requirement.

Advantages

Everything from the previous section about having separate files
You throw out all unnecessary code by only bundling the relevant code and maybe even minifying it

Disadvantages

You make assumptions about the environment of the users of your construct
It takes another build step and slightly increases the size of your CDK construct

Publish Lambda Function to Serverless Application Repository or Using Docker

A completely different option compared to the ones above is to use the Serverless Application Repository. It’s a repository for serverless application that you can build and publish to AWS using the SAM CLI. Then you can use this application in other stacks using the CloudFormation SAM type AWS::Serverless::Application. The CDK equivalent is CfnApplication from the @aws-cdk/aws-sam package. Since those applications can be made public to everyone, you have a neat way to host your Lambda function outside of your CDK construct, i.e. without bundling it inside your CDK construct. You could even share your AWS Lambda Layer in the same way and reference that instead of a full serverless application (see how to use Layers in AWS CDK here). This has the advantage that you can still use the Function construct as explained above and just add a LayerVersion construct. Similarly, you can publish your Lambda function as a container nowadays and reference that in your CDK construct. The CDK provides a DockerImageFunction for this case.

Although these options sound like a good idea because you are much more flexible in how your Lambda function is built, the solution has two disadvantages: First, you are referencing an unknown external stack or dependency that you should make your users aware of so they can verify it. Second, it adds much more complexity than often necessary. Especially if you’re using a Node.js runtime, none of these step should be necessary for bundling a Lambda function within your CDK construct. It’s much easier to use one of the other options above.

Advantages

Separation of concerns
Flexibility of which dependencies you need and how you provide them

Disadvantages

More complexity
Potential concerns by users

Conclusion

In most cases having separate files is totally enough. Especially if you just use the AWS SDK in your Lambda function, there’s often no need to over-optimize your code. However, as soon as you use other external dependencies, you have to do more to bundle a Lambda function within a CDK construct. My recommended approach is to bundle your Lambda function before you publish your CDK construct. Then, in your CDK construct just use the bundled artifact. As mentioned, the advantage is that you don’t make any assumptions about the (build) environments that the users of your CDK constructs have.

The post 5 Ways To Bundle a Lambda Function Within an AWS CDK Construct was first published on Sebastian Hesse - Software Engineer.

DEV Community: Sebastian Hesse

Migrating a CDK Construct to projen and jsii

About projen and jsii

Setup Your Construct Project

Migrating Your CDK Construct to projen

Updating Your Project Files with projen

Important General Settings

Release Settings

Location of Lambda Function Code

Building Your Construct

Custom Build or Workflow Steps

Publishing to Multiple Repositories Using jsii

Conclusion

Using Spring Boot On AWS Lambda: Clever or Dumb?

Some Context Around Spring Boot And AWS Lambda

Connecting AWS Lambda And Spring Boot

Advantages

Disadvantages

My Personal Opinion And Experience

Serverless Sending and Receiving E-Mails, the CDK Way

Setup Steps With AWS SES

AWS CDK Constructs to the Rescue

Deploy Your AWS CDK Stack

Sending E-Mails with AWS SES

Other Solutions

Conclusion

5 Ways To Bundle a Lambda Function Within an AWS CDK Construct

Problem Context

Inline Code in CDK Construct

Advantages:

Disadvantages

Separate File(s) in CDK Construct

Advantages

Disadvantages

Bundle Lambda Function Before Publishing

Advantages

Disadvantages

Bundle Lambda Function Before Deploying

Advantages

Disadvantages

Publish Lambda Function to Serverless Application Repository or Using Docker

Advantages

Disadvantages

Conclusion