Serverless Application Development with AWS CDK

By this point, you have acquired the skills needed to navigate AWS CDK with ease and can confidently apply CDK to your projects. Throughout this book, we have emphasized that CDK simplifies the maintenance of both traditional cloud applications, whether virtualized or containerized, as well as serverless application development. The challenges of serverless development have previously included the overwhelming amount of JSON and YAML code required to provision various components of a serverless stack. Fortunately, AWS CDK’s comprehensive toolkit makes managing these components significantly more manageable. The remaining chapters of this book will delve into various techniques for effectively working with AWS CDK and serverless architecture.

In the previous chapter, we learned how to test our CDK code. In this chapter, we are going to learn how to make our code serverless by ditching RDS and ECS for API Gateway and AWS Lambda...

Technical requirements

The source code for this chapter can be found at https://github.com/PacktPublishing/AWS-CDK-in-Practice/tree/main/chapter-7-serverless-application-development-with-aws-cdk.

The Code in Action video for this chapter can be viewed at: https://packt.link/WsOuj.

Since this chapter is a continuation of the previous one, the directory structure is the same but a few modifications have been made to the services, which we will explore in this chapter.

Configuring the project

Open this chapter’s code in your editor of choice. Just like in the previous chapters, we have divided the code into infrastructure, server, and web directories.

First, let’s go ahead and build the frontend for our application so that, just like in the previous chapter, CDK can upload the build directory’s contents to S3. Go to the web directory and, in the terminal, run the following command:

$ yarn

Follow this up with the following command:

$ yarn build:prod

Then, back in the infrastructure directory, run the following command:

$ yarn

This will install all the project’s dependencies.

Also, don’t forget to create the .env.production file with the required environmental variables.

With that sorted out, let’s move on to serverless computing.

What is serverless?

Serverless computing is a way of developing and running cloud-based apps and services without worrying about managing servers. Rather than setting up and maintaining servers as in traditional computing, the cloud provider (such as AWS) handles all the tedious server stuff for you. This means you can focus on writing code and developing your app.

Your app runs in response to events such as a user request or a message in a queue, and the cloud provider automatically handles the code execution and scales things up or down as needed. This saves you time and money while also lowering the risk of downtime and other problems.

As mentioned previously, with serverless computing, you can concentrate on what matters: the functionality of your app. The cloud provider handles all the technical aspects, allowing you to develop faster and take advantage of cutting-edge technology without worrying about compatibility issues.

It’s a win-win situation – it...

Completing and deploying the serverless backend

So far, we have successfully created a basic health check endpoint, which has helped you understand how to create Lambda-backed API endpoints. However, the current functionality of our health check endpoint is rather limited, as its name implies. In this section, we will delve deeper into querying and writing data to DynamoDB from the Lambda function handlers, allowing for more complex and useful API endpoints to be built.

Creating a GET and POST route to perform DynamoDB operations

Now that we have our API Gateway properly configured, to perform the same operations and requests we were doing with ECS and RDS, we need to create two more endpoints: one to fetch all data from the DynamoDB table, and another to insert data into it.

In this section, we’ll use our previous knowledge of creating an API Gateway method and integrating it with a Lambda function to create two more Lambdas connected to the DynamoDB table:

...

Introduction to Step Functions

AWS Step Functions is a workflow management service provided by AWS that enables you to create, execute, and visualize multistep operations or applications.

Think of Step Functions as a tool to streamline complex operations in a serverless environment by connecting and coordinating different tasks. These tasks can range from AWS Lambda functions to AWS Batch jobs to AWS Glue jobs. With Step Functions, you no longer have to manually perform each step of a workflow; instead, you just define the flow of your operations in a state machine and let Step Functions do the heavy lifting for you.

One of the key advantages of using step functions is the ability to keep track and provide a visual representation of the workflow. This makes it easier to understand what’s happening, since you can see exactly what’s going on and where things went wrong, making debugging and troubleshooting easier.

Step functions are widely used in applications...

Summary

In this chapter, we created and integrated Lambda functions and an API gateway to replace the RDS and ECS services. We created a DynamoDB table and set up a way to automatically seed it when deploying the stack and created a step function state machine linked to SES. We also set up a GET request to fetch all data from the DynamoDB table and a POST request to insert data into the same table and trigger the state machine. Finally, we added the API Gateway and DynamoDB constructs to our CDK stack and removed the ECS, RDS, and VPC constructs from the Stack. As you’ve experienced, the process of applying changes and testing serverless logic can be time-consuming. In the next chapter, we’ll explore ways to streamline building serverless applications, specifically by optimizing our local environment for faster and more efficient development.