In today's digital landscape, creating custom software to manage user data is crucial for organizations looking to gain insights and improve their operations. Many large-scale SaaS solutions collect, analyze, and leverage user information, but understanding how to build these capabilities from the ground up is essential for anyone looking to develop tailored applications. In this post, we'll walk through the steps to create a simple CRUD (Create, Read, Update, Delete) app using AWS and (in a subsquest post) Next.js. This hands-on guide will help you establish a practical foundation for building custom software that empowers organizations to collect, manage, and utilize user data effectively. Whether you're new to development or seeking to enhance your skills, this project will give you the tools to get started on building data-driven applications.

In this project, we'll be building and deploying a Next.js app running in ECS (Elastic Container Service) that will serve as the front-end, and AWS services like DynamoDB and Lambda which will serve as the back-end. We will store the data in DynamoDB (a NoSQL database) and use Lambda functions to perform our CRUD operations against the database. To get started, you will need to configure your local machine to run Terraform against an AWS account, set up your Terraform remote backend state resources, configure the Terraform provider.tf file, etc., there is a brief guide on how to do this with external links at the start of my first blog post. Additionally, code we'll be going over is available here on Github.

So let's get started, we will begin by provisioning our back-end with Lambda functions and a DynamoDB table, with the Lambda functions being created using my Lambda Terraform module which can be found here, also on Github.

However, before getting started, let's take some time to understand Lambda functions, what are they and how can they help us create our backend?

For this demonstration, we will work with the NONE authentication option, but if you want to explore using AWS_IAM instead, contact me and I can assist. Moving on, now that we understand what Lambda is, let's dive in. We will be creating four separate Lambda functions, each for the operations we'll be executing from our front-end app. Our operations will follow the RESTful API methodology, and if you're unfamiliar with RESTful, a definition is provided below:

• GET - fetch data from DynamoDB - source code
• POST - write new items to DynamoDB - source code
• PUT - update existing items in DynamoDB - source code
• DELETE - delete existing items from DynamoDB - source code

Definition: A RESTful API is a web service that allows different applications to communicate over HTTP by following a set of architectural principles. It treats everything as a resource, which is accessible via a unique URL, and uses standard HTTP methods like GET, POST, PUT, and DELETE to perform actions on these resources. RESTful APIs are stateless, meaning each request must contain all the necessary information, making them highly scalable and flexible. They are widely used due to their simplicity, scalability, and interoperability with different platforms and languages.

Take some time to look through the four Lambda functions' Node.js code, you'll see that I'm just calling DynamoDB functions from the AWS SDK (Software Development Kit) for Node.js, these functions imported will vary based on the RESTful methods associated with each function. The two functions running PUT and DELETE operations will expect data in the request's body, data such as the unique identifier for the item we will try to update or delete.

Before writing Terraform code for our Lambda functions, we need to prepare our configuration for the DynamoDB table the functions will execute operations against. Let's also understand what DynamoDB is and it's features.

resource "aws_dynamodb_table" "messages" {
  name         = var.APP_NAME
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "PK" # Partition key (unique identifier for the message)
  # Define table attributes
  attribute {
    name = "PK"
    type = "S"
  }
  tags = {
    Name = var.APP_NAME
  }
}

To maintain consistency across our Terraform configuration, we'll also define some variables we can use in our files. APP_NAME will be used to name our Lambda functions, DynamoDB table, ECS service, etc.

variable "APP_NAME" {
  type    = string
  default = "aws-next-js-crud-app"
  # ^ feel free to change this to whatever you want your 
  # app's name to be, keep in mind that this value will 
  # be used to name Lambda functions, the DynamoDB table 
  # and ECS service
}

variable "REGION" {
  type    = string
  default = "us-east-1"
}

variable "LAMBDA_PATH" {
  type    = string
  default = "lambda"
}

Now we can start to build out our Lambda functions, and as mentioned before, we will be using the Lambda module I personally manage, I use this module to statisfy a myriad of different needs across all my different apps, e.g., setting up Lambda to work as API Gateway integrations with Cognito authentication. Having said that, for this project we won't be using API Gateway or any sort of authentication. These Lambda functions will be exposed publically, hence function_url_public = true in the module instantiation, therefore, it might be a good idea to destroy your resources after you've tried things out.

module "lambda_get" {
  source              = "git::https://github.com/tldrlw/terraform-modules.git//apig-lambda"
  source_dir          = var.LAMBDA_PATH
  handler_file_prefix = "app-get"
  REST_method         = "GET"
  function_name       = "${var.APP_NAME}-get"
  environment_variables = {
    DYDB_TABLE_NAME = aws_dynamodb_table.messages.name,
    REGION          = var.REGION
  }
  is_s3                  = false
  is_dydb                = true
  dydb_table_arn         = aws_dynamodb_table.messages.arn
  dydb_table_permissions = ["dynamodb:Scan", "dynamodb:DescribeTable"]
  function_url_public    = true
}

module "lambda_post" {
  source              = "git::https://github.com/tldrlw/terraform-modules.git//apig-lambda"
  source_dir          = var.LAMBDA_PATH
  handler_file_prefix = "app-post"
  REST_method         = "POST"
  function_name       = "${var.APP_NAME}-post"
  environment_variables = {
    DYDB_TABLE_NAME = aws_dynamodb_table.messages.name,
    REGION          = var.REGION
  }
  is_s3                  = false
  is_dydb                = true
  dydb_table_arn         = aws_dynamodb_table.messages.arn
  dydb_table_permissions = ["dynamodb:BatchWriteItem"]
  function_url_public    = true
}

module "lambda_delete" {
  source              = "git::https://github.com/tldrlw/terraform-modules.git//apig-lambda"
  source_dir          = var.LAMBDA_PATH
  handler_file_prefix = "app-delete"
  REST_method         = "DELETE"
  function_name       = "${var.APP_NAME}-delete"
  environment_variables = {
    DYDB_TABLE_NAME = aws_dynamodb_table.messages.name,
    REGION          = var.REGION
  }
  is_s3                  = false
  is_dydb                = true
  dydb_table_arn         = aws_dynamodb_table.messages.arn
  dydb_table_permissions = ["dynamodb:DeleteItem"]
  function_url_public    = true
}

module "lambda_put" {
  source              = "git::https://github.com/tldrlw/terraform-modules.git//apig-lambda"
  source_dir          = var.LAMBDA_PATH
  handler_file_prefix = "app-put"
  REST_method         = "PUT"
  function_name       = "${var.APP_NAME}-put"
  environment_variables = {
    DYDB_TABLE_NAME = aws_dynamodb_table.messages.name,
    REGION          = var.REGION
  }
  is_s3                  = false
  is_dydb                = true
  dydb_table_arn         = aws_dynamodb_table.messages.arn
  dydb_table_permissions = [""]
  function_url_public    = true
}

Security: In our Lambda configurations, we're adhering to AWS's principle of least privilege by assigning only the necessary permissions for each function's specific tasks. For instance, lambda_get has read-only permissions (dynamodb:Scan, dynamodb:DescribeTable), while lambda_postis limited to write permissions (dynamodb:BatchWriteItem), ensuring each Lambda can only perform its required operations. This approach avoids over-permissioning and ensures that no unnecessary actions, such as wildcard permissions, are granted. Additionally, by referencing the specific DynamoDB table ARN (aws_dynamodb_table.messages.arn), we further restrict access to the intended table, preventing unauthorized access to other resources.

To enhance security, continue to review and audit these permissions regularly, ensuring that no Lambda has broader access than needed. It's also important to ensure that each function's permissions are explicitly defined and modular, as I've done withdydb_table_permissions in the Lambda module instantiation, ensuring future flexibility. This strategy keeps our functions secure, maintains control over access, and adheres to best practices in AWS IAM management. You can read more about the principle of least privilege here.

After provisioning our Terraform configuration thus far, we can test out these Lambda functions using their published function URL endpoints, so let's set up an outputs.tf file that will log the endpoints in the Terraform apply logs after the Lambda functions are created.

output "lambda_get_function_url" {
  value = module.lambda_get.function_url
}

output "lambda_get_arn" {
  value = module.lambda_get.arn
}

output "lambda_post_function_url" {
  value = module.lambda_post.function_url
}

output "lambda_post_arn" {
  value = module.lambda_post.arn
}

output "lambda_delete_function_url" {
  value = module.lambda_delete.function_url
}

output "lambda_delete_arn" {
  value = module.lambda_delete.arn
}

At this point, you can run the following Terraform commands from your local to provision all our resources to AWS. Despite still having the front-end infrastructure to set up, we can deploy the Lambda functions and test out their functionality using Postman, check out this guide on installing Postman, and this guide on how to make HTTP requests using endpoints.

• terraform init
• terraform plan
• terraform apply --auto-approve

Assuming your Terraform run went through at this point, the outputs should clearly delineate the endpoints corresponding to your four Lambda functions. Using these, you can test out the functionality of your new back-end APIs, see the screenshots below to understand what request parameters to add for the POST, PUT and DELETE calls you'll be making. While it's not safe for me to reveal my endpoints, I will be destroying these Lambda functions, in order to preclude malicious actors from taking advantage of this vulnerability and inundating my DynamoDB table with items, I suggest you do the same after you've completed this exercise. Running a simple terraform destroy should take care of that.

GET

POST

DELETE

PUT

When making DELETE or PUT calls, you can run the GET call and look at all the messages you've previously added to the table with the POST command, find the unique identifier for whatever you want to get rid of, or update, and include that as the messageId in the request's JSON body. For PUT calls, you'll also need to include a key-value pair with the key being newMessage. The Lambda functions' source code is configured to only accept these specific keys (messageId and newMessage), so be mindful of that. If you'd like, you can modify the source code to be able to take in other parameters in the request body, but for the purposes of this demonstration, I decided to keep it simple and work with "messages".

In part two of this series, we'll build out the Next.js front-end, where these APIs we just created can be used. It will be a simple form that allows users to see, delete, update existing messages and add new messages.