DEV Community: Pedram Hamidehkhan

Wing It: Cloud CRUD with Winglang

Pedram Hamidehkhan — Wed, 26 Nov 2025 20:55:13 +0000

When it comes to infrastructure as code, tools like Terraform, AWS CDK, and Pulumi immediately come to mind. Although these tools include testing capabilities, they often lack a fully integrated local simulation environment that accurately mimics cloud behavior. This gap can lead to longer, more expensive iteration cycles during development. Winglang addresses this challenge by providing a local simulator that mimics cloud behavior, enabling developers to test their code locally before deploying it to the cloud. Additionally, its simple and intuitive syntax and concept of preflight (static infrastructure code) and inflight (the application logic) code makes it easy for developers to work with cloud resources, regardless of their level of experience. In this post, we'll build a CRUD API using Winglang, deploy it to AWS, and build a GitOps workflow for the deployment and explore some of Winglang's key capabilities.

Prerequisites: Docker, Node.js, Terraform, AWS account

This post is organized in the following sections:
Outline:

Introduction to Winglang
Creating a CRUD API with Winglang
Deploying the API to AWS
Enabling a GitOps Workflow
Conclusion

Introduction to Winglang

Winglang is a high-level language that abstracts away the complexity of cloud infrastructure so you can focus on application logic. It unifies resource provisioning (preflight code) with dynamic operations (inflight code):

Preflight: Code that runs at compile time to set up static resources (e.g., VPCs, subnets).
Inflight: Code that runs at runtime to manage dynamic operations (e.g., ECS Containers, AWS Lambda).

Even though Winglang facilitates development in the cloud for non-experts and folks with little to no infra exposure, I think its main superpower is its local simulator. The local simulator gives you a simulation of all the resources in your code and you can interact with them as if they were already deployed. For example, you can make API calls to validate if things get persisted in your database or if a notification gets triggered when a certain event occurs in the system. This can bring meaningful cost savings in the DevOps cycle as we shift testing to the left.

Creating a CRUD API with Winglang

In this section, we will create a simple CRUD API using Winglang. Firstly please ensure you have installed Winglang on your machine. You can do this by running the following command:

npm install -g Winglang

Next, we can “import” the modules we want to interact with—or as Winglang expresses it, “bring” the modules we need:

bring cloud;    // this will bring all the cloud modules
bring dynamodb; // for database
bring http;     // for testing our APIs in the local simulator
bring expect;   // for testing

I'd like to persist the data in a DynamoDB table, but you can of course opt for a bucket or any other DB choice you are more comfortable with. Here is the code:

let messagesTable = new dynamodb.Table(
  attributes: [
    {
      name: "id",
      type: "S"
    }
  ],
  hashKey: "id"
);

Now if you notice, this code is considered preflight because it is static and it will run at compile time. The table will be created when the code is compiled and the table will be available when the code is deployed.

Next I am going to ask Wing to create an API for me that will interact with the table:

let api = new cloud.Api();

Then I'd like to also create a counter, which lets me change the ID of the items that are being saved in DynamoDB:

let messageCounter = new cloud.Counter();

This is again preflight code and static in nature. Now let's see how inflight code operates by creating a POST method on our API which persists data to our database.

api.post("/messages", inflight (request) => {
  let newMessage = Json{
    id: messageCounter.inc(),
    message: request.body
  };
  log("New message: {Json.stringify(newMessage)}");

  let recordId = messageCounter.inc();
  messagesTable.put(
    Item: {
      id: Json.stringify(recordId),
      message: newMessage
    }
  );
  return {
    status: 200,
    headers: {
      "Content-Type" => "text/html",
      "Access-Control-Allow-Origin" => "*",
    },
    body: Json.stringify(newMessage),
  };
});

So as you can see, contrary to previous objects, we annotated this one with the inflight keyword. This means that this code will run at runtime and it will be executed.

Before deploying I'd like to add one final step, which is testing our API. To that end I added the following tests:

let validateResponse = inflight(response: http.Response, expectedContent: str) => {
  log("Response status: {response.status}");
  expect.equal(response.status, 200);
  assert(response.body?.contains(expectedContent) == true);
};

test "messages API returns correct response" {
  let response = http.post("{api.url}/messages", {
    body: "xyz",
  });
  log("Response body: {response.body}");
  assert(response.body?.contains("xyz") == true);
}

Now run the following command to start the local simulator (Docker must be running):

wing it

Now you should see the simulator like depicted in the image below:

The simulator allows you to try many different aspects of your code to ensure that it works as expected. You can make API calls, check the logs, and even interact with the database. This is a very powerful tool that can help you to test your code before deploying it to the cloud.

Deploying the API to AWS

After successfully testing the code in the local simulator, we can now deploy the code to AWS. To do this, we need to compile the code to the platform of our choice. In this case I opted for Terraform, but AWS CDK should also be supported. Here is the command to compile the code:

wing compile -t tf-aws main.w

This code will generate the Terraform code necessary to be deployed on AWS. You can navigate to target/main.tfaws and examine the generated files. Of course, at this point you can run the following Terraform commands to deploy the changes to AWS:

terraform init
terraform apply

As this will create a local state file and does not enable a GitOps workflow, I'd like to show you how you can enable a GitOps workflow with Winglang.

Enabling a GitOps Workflow

To enable a GitOps workflow with Winglang, there is one addition that we need in our Wing code which can be stored as a JavaScript file in the root of the project. Here is the code:

exports.Platform = class TFBackend {
    postSynth(config) {
        config.terraform.backend = {
        s3: {
            bucket: process.env.TF_BACKEND_BUCKET,          
            region: process.env.TF_BACKEND_REGION,          
            key: "state/terraform.tfstate",
            dynamodb_table: process.env.TF_BACKEND_TABLE    
        }
        };
        return config;
    }
}

This will ensure that the Terraform state is stored in an S3 bucket and a DynamoDB table is used to lock the state. This is necessary to enable a GitOps workflow with Winglang. The script.sh file in the repository should help with the creation of the S3 and DynamoDB resources.
To improve things a bit further, we can also add a GitHub Action that will run the Winglang commands and deploy the code to AWS. Here is a link to the GitHub Action file.
Now before everything falls in place, we need to create a GitHub repository and push the code to the repository. After that, we need to create a secret in the repository for AWS credentials as well as the Terraform state file. Of course the recommended approach is to use GitHub OIDC to authenticate with AWS, but for simplicity I created a temporary IAM user with minimal permissions and generated an access key for it.
Now you can add all these secrets and variables in GitHub as variables in the repository settings. So the ones required by AWS are:

AWS_ACCESS_KEY_ID
AWS_REGION
AWS_SECRET_ACCESS_KEY
TF_BACKEND_BUCKET: [Terraform] the name of the s3 bucket
TF_BACKEND_TABLE: [Terraform] the name of the dynamodb table

Now you can push the code to the repository and the GitHub Action should run and deploy the code to AWS. You can check the status of the action in the Actions tab in the repository.

Conclusion

In this post, we have seen how to create a simple CRUD API using Winglang and deploy it to AWS. We have also seen how to enable a GitOps workflow with Winglang. Winglang is a powerful tool that can help developers to build and deploy cloud applications with ease. It provides a simple and intuitive syntax that makes it easy to work with cloud resources. It also provides a local simulator that allows developers to test their code before deploying it to the cloud. I hope this post has been helpful and that you have learned something new. If you have any questions or comments, please feel free to leave them below. Thank you for reading!

Collaborative Infrastructure as Code using Terraform Cloud - Publishing Modules Private Registries

Pedram Hamidehkhan — Wed, 22 Jun 2022 16:47:08 +0000

I'd like to start this post with a great quote from The DevOps Handbook which says: "When new learnings are discovered locally, there must also be some mechanism
to enable the rest of the organization to use and benefit from that knowledge." Infrastructure as Code is not a new concept and it is already used in many projects. However, collaborating on IaC has not always been easy for developers. Many organization are struggling with sharing the knowledge and expertise of their developers with other teams. This is a difficult problem that private registries Terraform Cloud/Enterprise is aiming to solve.

In a previous post, we had a go on solving the cold starts for Lambda Functions. Now we want to help the next person in our team preventing them from reinvent the wheel again.

This tutorial assumes you already have a Terraform Cloud account, if you haven't opened up an account yet, please use the links bellow to open one.

https://cloud.hashicorp.com/products/terraform

So how do you go about creating a private registry?

We begin by creating the module that you'd like to publish. I am using this module. I personally prefer adding variables with smart defaults as much as I can. Of course, the consumer of this module is also going to need some of the outputs of this module to be used in their application, e.g. the ARN of the lambda function. so don't forget to add them in the output section.

After creating the module, we are ready to push it into Github. Please also be aware of the naming convention for your module, which follow the "terraform--" pattern.
Before we jump to terraform cloud, we need to build a release for our project in Github, follow this this to build the release, OR, click on releases on the right pane of your repository, click on "draft a new release" choose a tag for the release (should follow x.y.z versioning pattern), give it a title and click on publish, and we are good to go.

Now jump to Terraform Cloud, and click on registry, then click on modules, publish, modules. If you don't see your VCS provider, you need to connect it with Terraform cloud before proceeding, please visit this link to do so.

Choose your repository, and click on Publish module!

Congratulations on publishing your first Terraform Module.

In the next post, I will show you how to consume this module and integrate it into a bigger application.

The link to the Video: https://youtu.be/S5JTD3hWOug

Github repo: https://github.com/pedramha/terraform-aws-lambda

Solving the Cold Start Challenge for Lambda Function Using Terraform Cloud

Pedram Hamidehkhan — Fri, 10 Jun 2022 09:07:16 +0000

In this post we are going to properly address the cold starts for Lambda Functions. In a later post we will create a private module which facilitates consumption of this module.

Start in an empty directory and create the following files:

    "main.tf"
    "variables.tf"
    "output.tf"
    "terraform.auto.tfvars"

In the "main.tf" file add the following to it.

    provider "aws" {
        region = "eu-central-1"
    }

One quick note: please NEVER add your credentials here! Ideally, store credentials as environment variables in Terraform Cloud.
Now open the terminal and execute the "terraform init" command. This will initialize our directory with the AWS provider.
To deploy the lambda function, we will need to upload the packaged code to S3. So I am also leveraging the random provider to make sure that the S3 Bucket is unique.

    resource "random_pet" "lambda_bucket_name" {
      prefix = "test"
      length = 4
    }


    resource "aws_s3_bucket" "lambda_bucket" {
      bucket = random_pet.lambda_bucket_name.id
      acl    = "private"
        tags = {
        "env" = "test"
      }
    }

The two resources above will just create a random bucket.
The following command will allow me to package the code before uploading it to S3 (I prefer to avoid the local executioner whenever possible):

    data "archive_file" "lambdaFunc_lambda_bucket" {
      type = "zip"

      source_dir  = var.src_path
      output_path = var.target_path
    }

After that I create the bucket for my deployment artifact:

    resource "aws_s3_bucket_object" "lambdaFunc_lambda_bucket" {
      bucket = aws_s3_bucket.lambda_bucket.id

      key    = var.target_path
      source = data.archive_file.lambdaFunc_lambda_bucket.output_path

      etag = filemd5(data.archive_file.lambdaFunc_lambda_bucket.output_path)
        tags = {
        "env" = "test"
      }
    }

Now things get more interesting. When you deploy a lambda function, you can specify a few parameters that are relevant when you want to deploy in production. One is of course, the reserved concurrency. AWS limits the number of concurrent executions per account and per region.

Therefore for having predictability for our concurrency and not having our Lambda function throttled by other lambdas, we set this parameter.

    resource "aws_lambda_function" "lambdaFunc" {
      function_name = var.function_name

      s3_bucket = aws_s3_bucket.lambda_bucket.id
      s3_key    = aws_s3_bucket_object.lambdaFunc_lambda_bucket.key

      runtime = var.lambda_runtime
      handler = var.handler

      source_code_hash = data.archive_file.lambdaFunc_lambda_bucket.output_base64sha256

      role                           = aws_iam_role.lambda_exec.arn
      reserved_concurrent_executions = var.concurrent_executions
      tags = {
        "env" = "test"
      }
    }

Now we get to the most important port, Cold Start. As officially suggested by AWS, I will be leveraging provisioned concurrency to deploy the lambda function. There are many solutions which use aws cloud watch as rules, but I really believe that provisioned concurrency is much simpler and comfortable to use. Moreover, in order to use the provisioned concurrency, we will need to create an Alias. This Alias can also serve as a way to do Blue Green or Canary deployments, which we will hopefully cover in a future post.

    resource "aws_lambda_alias" "con_lambda_alias" {
      name             = "lambda_alias"
      description      = "for blue green deployments OR for concurrency"
      function_name    = aws_lambda_function.lambdaFunc.arn
      function_version = var.function_version
    }

    resource "aws_lambda_provisioned_concurrency_config" "config" {
      function_name                     = aws_lambda_alias.con_lambda_alias.function_name
      provisioned_concurrent_executions = var.provisioned_concurrent_executions
      qualifier                         = aws_lambda_alias.con_lambda_alias.name
    }

Please note that I used variables as the value for these parameters. These variables have defaults. Feel free to change them as your use case requires. Also please be aware that the provisioned concurrency is going to cost you as AWS keeps a warm instance of your application somewhere.

Lastly, we need a basic policy for our lambda function.

    resource "aws_iam_role" "lambda_exec" {
      name = "serverless_lambda"
      assume_role_policy = jsonencode(
        {
          "Version" : "2012-10-17",
          "Statement" : [
            {
              "Effect" : "Allow",
              "Principal" : {
                "Service" : "lambda.amazonaws.com"
              },
              "Action" : "sts:AssumeRole"
            }
          ]
        }
      )
    }

In the "variables.tf" file add the following to it:

    variable "function_name" {
      type    = string
      default = "test-function"
    }

    variable "src_path" {
      type = string
    }

    variable "target_path" {
      type = string
    }

    variable "lambda_runtime" {
      type    = string
      default = "nodejs12.x"
    }

    variable "handler" {
      type    = string
      default = "index.handler"
    }

    variable "region" {
      type    = string
      default = "eu-central-1"
    }

    variable "concurrent_executions" {
      type    = string
      default = "1"
    }

    variable "provisioned_concurrent_executions" {
      type    = string
      default = "1"
    }

    variable "function_version" {
      type    = string
      default = "1"
    }

And in the "terraform.auto.tfvars" file add the following content:

    src_path    = "./src"  //the path to the source code for lambdafunction
    target_path = "./artifacts/lambda_deployment.zip" //the path for the deployment artifact

You can of course bring your own lambda function, but if you don't have one, create a folder called "src and a file in it called "index.handler" and add the following to it:

    exports.handler =  async (event) => {
      const payload = {
        date: new Date(),
        message: 'Terraform is awesome!'
      };
      return JSON.stringify(payload);
    };

Now you can deploy the application using Terraform CLI or Terraform Cloud. For the CLI version, simply run

    "terraform apply -auto-approve"

If you want to use Terraform Cloud to have "GitOps" use the following documentation:

https://www.hashicorp.com/resources/a-practitioner-s-guide-to-using-hashicorp-terraform-cloud-with-github

This problem might have been difficult to solve, but I can guarantee that it is much harder to communicate the solution to someone properly.
I will create another blog post explaining how you can optimally share this solution with someone inside your organization.

GitHub Repository: https://github.com/pedramha/terraform-aws-lambda
Youtube: https://www.youtube.com/watch?v=e0QplrqH0J4

Thank you!
Pedram

Basic serverless CRUD Application with CDK for Terraform

Pedram Hamidehkhan — Fri, 01 Apr 2022 14:00:50 +0000

In this post, we will build a basic serverless CRUD application on AWS using CDK for Terraform. In a previous post we created a simple hello world applicaiton, but in this one, we persist the data using dynamo db and we add some functionality to the applicaiton. Addiditionally we add some security to our API.

First thing's first, let's initialize a CDKTF project. Similar to Cloudformation CDK, you can run the following command to initialize the project:

cdktf init

Then it will ask you for the language of your choice and name and description for your project. I opted for Typescript but you can use whatever language you are comfortable with.
The "cdktf init" command will create the project structure for us. As you might know, Terraform has a very large provider ecosystem. To continue with the project, you need to specify which provider you want to use. To do that, open the cdktf.json and change the "terraformProviders" section to:

  "terraformProviders": [
    "aws@>3.0"
  ]

Of course, you can use the version of your choice. After that, you need to run the following command to pull down the providers:

cdktf get

OR:

 npm run get

Now we are ready to begin. In the main.ts file, add the following imports:

import { Construct } from "constructs";
import { App, AssetType, TerraformAsset, TerraformStack, TerraformOutput } from "cdktf";
import { lambdafunction, s3, apigateway, iam, AwsProvider, dynamodb } from "@cdktf/provider-aws";
import * as path from "path";

It is worth mentioning, that unlike Cloudformation CDK, you will get a compile error if you have unused imports or variables in your code.
Now add the following code to specify the provider:

new AwsProvider(this, "aws", {
  region: "eu-west-1"
});

You also need to specify where your lambda function is. I created a folder called "src" and used TerraformAsset to import it as follows:

const asset = new TerraformAsset(this, "asset", {
  path: path.resolve(__dirname,'./src'),
  type:AssetType.ARCHIVE
});

Now we need to create the S3 Bucket and Object to upload our TerraformAsset function:

const assetBucket = new s3.S3Bucket(this, "assetBucket", {
  bucket:"a-unique-bucket-name"
});

const lambdaArchive = new s3.S3BucketObject(this, "lambdaArchive", {
  bucket: assetBucket.bucket,
  key: asset.fileName,
  source: asset.path,
  sourceHash: asset.assetHash // to inform cdktf of changes in file
});

Now we can create our database:

const db = new dynamodb.DynamodbTable(this, "db", {
  name: "my-table",
  billingMode: "PAY_PER_REQUEST",
  hashKey: "id",
  attribute: [
    {
      name: "id",
      type: "S"
    }
  ]
});

Then create the IAM Policy and Role for the lambda function:

const lambPolicy = {
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
};

const role = new iam.IamRole(this, "role", {
  assumeRolePolicy: JSON.stringify(lambPolicy),
  name: "my-lambda-role"
});


new iam.IamRolePolicyAttachment(this, "rolePolicy", {
  policyArn: "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole",
  role: role.name
});

//we can use a managed policy to access our db
new iam.IamRolePolicyAttachment(this, "rolePolicyDB", {
  policyArn: "arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess",
  role: role.name
});

After that, we can specify the configuration of our lambda function:

const lambdaFunc = new lambdafunction.LambdaFunction(this, "lambdaFunc", {
  functionName: "my-lambda-function",
  runtime: "nodejs14.x",
  handler: "index.handler",
  role: role.arn,
  s3Bucket: assetBucket.bucket,
  s3Key: lambdaArchive.key,
  sourceCodeHash: lambdaArchive.sourceHash,
  environment: {
    variables: {
      "TABLE_NAME": db.name,
      "PRIMARY_KEY": 'itemId',
    }
  }
});

I added the table name and PK as environment varaibles.

Then, we create an API Gateway to receive HTTP Requests from the Internet. We can also add the resources to our API and define HTTP Methods:

const restApi = new apigateway.ApiGatewayRestApi(this, "restApi", {
  name: "my-rest-api",
  description: "my-rest-api"
});

const resourceApi = new apigateway.ApiGatewayResource(this, "resourceApi", {
  restApiId: restApi.id,
  parentId: restApi.rootResourceId,
  pathPart: "my-resource",
});

const postApi = new apigateway.ApiGatewayMethod(this, "postApi", {
  restApiId: restApi.id,
  resourceId: resourceApi.id,
  httpMethod: "POST",
  authorization: "NONE"
});

const getApi = new apigateway.ApiGatewayMethod(this, "getApi", {
  restApiId: restApi.id,
  resourceId: resourceApi.id,
  httpMethod: "GET",
  authorization: "NONE"
});

const putApi = new apigateway.ApiGatewayMethod(this, "putApi", {
  restApiId: restApi.id,
  resourceId: resourceApi.id,
  httpMethod: "PUT",
  authorization: "NONE"
});

const delApi = new apigateway.ApiGatewayMethod(this, "delApi", {
  restApiId: restApi.id,
  resourceId: resourceApi.id,
  httpMethod: "DELETE",
  authorization: "NONE"
});

We also need to add API integrations to our methods as follows:

new apigateway.ApiGatewayIntegration(this, "apiIntegration", {
  restApiId: restApi.id,
  resourceId: resourceApi.id,
  httpMethod: postApi.httpMethod,      
  integrationHttpMethod: "POST",
  type: "AWS_PROXY",
  uri: lambdaFunc.invokeArn
});

new apigateway.ApiGatewayIntegration(this, "apiIntegration2", {
  restApiId: restApi.id,
  resourceId: resourceApi.id,
  httpMethod: getApi.httpMethod,      
  integrationHttpMethod: "POST",
  type: "AWS_PROXY",
  uri: lambdaFunc.invokeArn
});

new apigateway.ApiGatewayIntegration(this, "apiIntegration3", {
  restApiId: restApi.id,
  resourceId: resourceApi.id,
  httpMethod: putApi.httpMethod,
  integrationHttpMethod: "POST",
  type: "AWS_PROXY",
  uri: lambdaFunc.invokeArn
});

new apigateway.ApiGatewayIntegration(this, "apiIntegration4", {
  restApiId: restApi.id,
  resourceId: resourceApi.id,
  httpMethod: delApi.httpMethod,
  integrationHttpMethod: "POST",
  type: "AWS_PROXY",
  uri: lambdaFunc.invokeArn
});

Note that integrationHttpMethod is always set to POST:

Finally, you need to create a LambdaPermission Policy to allow the API Gateway to invoke our Lambda Function:

new lambdafunction.LambdaPermission(this, "apig-lambda", {
  statementId: "AllowExecutionFromAPIGateway",
  action: "lambda:InvokeFunction",
  functionName: lambdaFunc.functionName,
  principal: "apigateway.amazonaws.com",
  sourceArn: `${restApi.executionArn}/*/*`      
});

Now we have our API and Lambda Function Integrations. We can go ahead and deploy our API into a Stage. However, we should secure our API, because at this point, it will be reachable from the Internet.

So we create a deployment for our API and add a stage:

const apiDepl = new apigateway.ApiGatewayDeployment(this, "deployment", {
  restApiId: restApi.id,
  dependsOn: [lambdaFunc]
});

const apiStage = new apigateway.ApiGatewayStage(this, "stage", {
  restApiId : restApi.id,
  stageName: "test",
  deploymentId: apiDepl.id,
  dependsOn: [apiDepl]
});

I also added the "dependsOn" property to make sure certain resources will be created before others.

Now we can create an API Key for our API:

const apiKey = new apigateway.ApiGatewayApiKey(this, "apiKey", {
  name: "my-api-key",
  description: "my-api-key",
  enabled: true
});

After that, we need to create a usage plan and attach the api key to it. The Usage plan gives you a lot of control over how your API is used.

const usagePlan = new apigateway.ApiGatewayUsagePlan(this, "usagePlan", {
  name: "my-usage-plan",
  description: "my-usage-plan",
  throttleSettings: {
    burstLimit: 10,
    rateLimit: 10
  },
  apiStages: [
    {
      apiId: restApi.id,
      stage: apiStage.stageName
    }
  ],
  dependsOn: [apiKey]
});

new apigateway.ApiGatewayUsagePlanKey(this, "usagePlanKey", {
  keyId: apiKey.id,
  keyType: "API_KEY",
  usagePlanId: usagePlan.id,
  dependsOn:[usagePlan]
});

Note that I limited the rate and burst limit to make sure the costs will be in control.

If you like to see the endpoint of your API and test it curl or postman, you can use the following command:

new TerraformOutput(this, "apiUrl", {
  value: apiStage.invokeUrl,
  description: "API URL"
});

Don't forget to add your lambda function in the "src" folder; create a file called index.ts and add the functionality that you want. I only wanted to send a hello world response:

import * as AWS from 'aws-sdk';
import { v4 as uuidv4 } from 'uuid';

const db = new AWS.DynamoDB.DocumentClient({ apiVersion: '2012-08-10', region: 'eu-west-1' });
const TABLE_NAME = process.env.TABLE_NAME || '';
const PRIMARY_KEY = process.env.PRIMARY_KEY || '';

export const handler = async (event: any = {}): Promise<any> => {
  if (event.httpMethod === 'POST') {
    try {
      if (!event.body) {
        return { statusCode: 400, body: 'invalid request, you are missing the parameter body' };
      }
      const item = typeof event.body == 'object' ? event.body : JSON.parse(event.body);
      item[PRIMARY_KEY] = uuidv4();
      const params = {
        TableName: TABLE_NAME,
        Item: item
      };

      return await db.put(params).promise();
    } catch (error) {
      return { statusCode: 500, body: error };
    }
  }
  else if (event.httpMethod === 'GET') {
    //get all items
    try {
      const params = {
        TableName: TABLE_NAME
      };
      const resp = await db.scan(params).promise()
      return { statusCode: 200, body: JSON.stringify(resp.Items) };
    } catch (error) {
      return { statusCode: 500, body: error };
    }
  }

  else if (event.httpMethod === 'PUT') {
    try {
      if (!event.body) {
        return { statusCode: 400, body: 'invalid request, you are missing the parameter body' };
      }
      const item = typeof event.body == 'object' ? event.body : JSON.parse(event.body);
      const params = {
        TableName: TABLE_NAME,
        Item: item
      };
      return await db.put(params).promise();
    } catch (error) {
      return { statusCode: 500, body: error };
    }
  }
  else if (event.httpMethod === 'DELETE') {
    try {
      if (!event.pathParameters) {
        return { statusCode: 400, body: 'invalid request, you are missing the parameter pathParameters' };
      }
      const params = {
        TableName: TABLE_NAME,
        Key: {
          [PRIMARY_KEY]: event.pathParameters[PRIMARY_KEY]
        }
      };
      return await db.delete(params).promise();
    } catch (error) {
      return { statusCode: 500, body: error };
    }
  }
};

I will explain this lambda function in a separate post.
You can create this lambda function without packaging it. But I'd like to package it before deploying to make sure that I have all the dependencies that I need:
So I create a file called "package.json" and add the following:

{
    "name": "lambda-crud-dynamodb",
    "version": "1.0.0",
    "description": "Lambdas to do CRUD operations on DynamoDB",
    "private": true,
    "license": "MIT",
    "devDependencies": {
      "@types/node": "*",
      "@types/uuid": "*"
    },
    "dependencies": {
      "aws-sdk": "*",
      "uuid": "*"
    }
}

Regarding deploying this code, you will find your way if you have used CDK Cloudformation or Terraform HCL.
You can run the following commands to deploy the project:

npm run build
cdktf plan OR cdktf synth
cdktf apply OR cdktf deploy

The youtube video: https://youtu.be/sf2EgmHRHiw

Github: https://github.com/pedramha/cdktf-aws-example

Building a Sample Lambda Function and API Gateway with CDK for Terraform

Pedram Hamidehkhan — Fri, 04 Feb 2022 15:35:37 +0000

In this post, you learn how to use CDK for Terraform to build a sample serverless application on AWS. We are going to use AWS lambda and API Gateway to build this application.

First thing's first, let's initialize a CDKTF project. Similar to Cloudformation CDK, you can run the following command to initialize the project:

cdktf init

  "terraformProviders": [
    "aws@>3.0"
  ]

Of course, you can use the version of your choice. After that, you need to run the following command to pull down the providers:

cdktf get

Now we are ready to begin. In the main.ts file, add the following imports:

import { Construct } from "constructs";
import { App, AssetType, TerraformAsset, TerraformOutput, TerraformStack } from "cdktf";
import {lambdafunction, s3, apigatewayv2, iam, AwsProvider} from "./.gen/providers/aws"
import path = require("path");

It is worth mentioning, that unlike Cloudformation CDK, you will get a compile error if you have unused imports or variables in your code.
Now add the following code to specify the provider:

new AwsProvider(this, "aws", {
  region: "eu-west-1"
});

You also need to specify where your lambda function is. I created a folder called "src" and used TerraformAsset to import it as follows:

const asset = new TerraformAsset(this, "asset", {
  path: path.resolve(__dirname,'./src'),
  type:AssetType.ARCHIVE
});

Now we need to create the S3 Bucket and Object to upload our TerraformAsset function:

const assetBucket = new s3.S3Bucket(this, "assetBucket", {
  bucket:"a-unique-bucket-name"
});

const lambdaArchive = new s3.S3BucketObject(this, "lambdaArchive", {
  bucket:assetBucket.bucket,
  key:asset.fileName,
  source:asset.path
});

Then create the IAM Policy and Role for the lambda function:

const lambdaRole = {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Sid": "",
}
]
};

const role = new iam.IamRole(this, "role", {
  assumeRolePolicy: JSON.stringify(lambdaRole),
  name: "my-lambda-role"
});

new iam.IamRolePolicyAttachment(this, "rolePolicy", {
  policyArn: "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole",
  role: role.name
});

After that, we can specify the configuration of our lambda function:

const lambdaFunc = new lambdafunction.LambdaFunction(this, "lambdaFunc", {
  functionName: "my-lambda-function",
  runtime: "nodejs14.x",
  handler: "index.handler",
  role: role.arn,
  s3Bucket: assetBucket.bucket,
  s3Key: lambdaArchive.key
});

Then, we create an API Gateway to receive HTTP Requests from the Internet:

const api = new apigatewayv2.Apigatewayv2Api(this, "api", {
  name: name, 
  protocolType: "HTTP",
  target: lambdaFunc.arn
});

Finally, you need to create a LambdaPermission Policy to allow the API Gateway to invoke our Lambda Function:

new lambdafunction.LambdaPermission(this, "apig-lambda", {
  functionName: lambdaFunc.functionName,
  action: "lambda:InvokeFunction",
  principal: "apigateway.amazonaws.com",
  sourceArn: `${api.executionArn}/*/*`,
});

If you like to see the endpoint of your API and test it curl or postman, you can use the following command:

new TerraformOutput(this, "apiUrl", {
  value: api.apiEndpoint
});

Don't forget to add your lambda function in the "src" folder; create a file called index.ts and add the functionality that you want. I only wanted to send a hello world response:

export const handler = async () => {
    return { statusCode: 200, body: 'hello world'  };
}

Regarding deploying this code, you will find your way if you have used CDK Cloudformation or Terraform HCL.
You can run the following commands to deploy the project:

npm run build
cdktf plan OR cdktf synth
cdktf apply OR cdktf deploy

The youtube video: https://youtu.be/3rVgMYc7jkg
Github: https://github.com/pedramha/cdktf-aws-example

Create Static Website on AWS using Terraform

Pedram Hamidehkhan — Wed, 19 Jan 2022 17:35:24 +0000

In this post, you learn how to use Terraform to create a static website on AWS. This example is suitable for scenarios where you have a frontend team working on a static web application. (not ideal for dynamic websites like mvc applications in ASP.NET) Moreover, you would generally use such pattern in larger applications, not for small blogs or single page applications.

First thing's first, let's initialize a Terraform project project. To do that create a file called configuration.tf (the name doesn't really matter, only the suffix) and add the following:

provider "aws" {
  region = "eu-central-1"
}

Then run the following command to initialize the project:

Terraform init

Using the configuration.tf file, terraform will know that provider you need and pulls the dependencies for you.

Then, in the main.tf file (create it if it doesn't exist) create a s3 bucket using the following command:

    resource "aws_s3_bucket" "bucket" {
      bucket = "youruniquebucketname"
      acl    = "public-read"

      provisioner "local-exec" {
          command = "aws s3 sync static/ s3://${aws_s3_bucket.bucket.bucket} --acl public-read --delete"

      }

      website {
        index_document = "index.html"
      }

    }

In the first line, you create the bucket resource, second line is the name, the next is the access control list (must be public). The provisioner resource will copy a basic aws command, syncing the contents of the static folder (which is where you put your static content) to the bucket. You could also use the copy command, but I find sync more convenient, as it also can delete files in the target bucket.
At last, you can also make sure that index_document is pointing to your index.html file.

Then go ahead and paste your static content in the static folder.
Now we can deploy to AWS.
Use "terraform plan" to see what will be deployed. Then, using "terraform apply" you can deploy to your aws account.

The youtube video: https://www.youtube.com/watch?v=UU3drURkTtw

Easiest way to create a serverless backend in AWS using UI

Pedram Hamidehkhan — Wed, 12 Jan 2022 17:30:39 +0000

I've recently discovered a new way to create serverless backend in AWS using the GUI. Of course, creating lambda functions and dynamodb tables through the UI isn't really difficult. The main point is to get everything as Code at the end. This is a really long awaited feature in aws, which is finally being delivered. Now you can configure your infrastructure through the AWS console, and then export it as code. You can use CDK or SAM as the export target. A similar feature has been offered by azure (exporting ARM templates), but it is great to see AWS is offering this feature.

As opposed to previous posts, in this one we only work with the GUI (AWS Console).

So after logging in to the aws console, go to Lambda section and click on Applications.

After that you see the following options:

As you can see, you can not do everything using this method, but you have quite a few options.
We go ahead and create a Serverless Backend API. This will generate a new API Gateway, a few Lambda Functions and a DynamoDB Table.
Please note that at this moment only Node.js 14 is supported. It is also worth mentionning that the generated code can be exported to github or to aws code commit.

So go ahead and click on next to go to the page where you can specify your application name, github/codecommit repository and whether you want the export to be SAM or CDK. If you want to export to github, you need to make a connection between your aws account and github. Click on "Connect with CodeStar Connections". In the popup window choose a name fo the connection and click "connect to github". After that a pop-up window will appear, asking you for your credentials. After entering your credentials your connection is there and you can go ahead and click on "create" on the bottom of the page.

And that is IT! it takes a few minutes for all the resources to be created and for the code to be available in github. The cherry on top is, that using this method you already get a functioning CICD pipeline! As a matter of fact, aws configures code Pipeline and CodeBuild and connects them to your github repository for you. So every time you make a change and push it to github, the change will be automatically deployed to aws.

It might be a bit difficult to follow using only text, so I went ahead and created a vide, which hopefully will be easier to follow.

    Youtube: https://youtu.be/z8lDx2l7f0w

That is it. Thank you very much for reading this post.

Building on AWS Using Github Copilot and AWS CDK

Pedram Hamidehkhan — Mon, 08 Nov 2021 19:21:47 +0000

In this post we are going to have a look at Github's Copilot and how we can leverage it spin up some resources using AWS CDK.
Copilot is still in technical preview. But if you already signed up for it and are lucky enough like me to have access to it, you can enable it as a simple VS Code extension.
Of course, I do not expect for the Copilot to be very mature, as it is not publicly released yet, but I believe it seems very promising and arguably it changes the way we think about software development. Just like driving assistance systems, which are not a replacement for a driver, Github Copilot will also not replace developers, but rather empowers them.
There are already many videos on youtube and blog posts explaining basic functions that Copilot automatagically generates. In this post though, we try to see how it can be used in a serverless/aws world.
As you might already know, copilot uses billions of lines of code on Github, to give you suggestion while coding. It actually is even giving me suggestions a I am writing this post. What I am going to do is to perform the same tasks I did in this post using Copilot.
Some of the things I explain here are a bit difficult to grasp in writing form, so I will explain them in a video in a later parts of this post.

So as always, first thing's first, let's initialize an empty CDK typescript project:

cdk init --language=typescript.

Then we go to package.json to declare the dependencies for our project.
Add the following modules the dependencies:

npm install @aws-cdk/aws-ecs @aws-cdk/aws-ecs-patterns @aws-cdk/aws-ecr-assets --save

By default, CDK deploys the VPC for you, but if you want control over your VPC, go ahead and import EC2 Module and add the VPC.
Then go to the lib folder and the typescript file for your application stack.

Add the following import statements to before class declaration:

import cdk = require("@aws-cdk/core");
import apigateway = require("@aws-cdk/aws-apigateway");
import dynamodb = require("@aws-cdk/aws-dynamodb");
import lambda = require("@aws-cdk/aws-lambda");
import { RemovalPolicy } from "@aws-cdk/core";
import { create } from "domain";
import { BillingMode } from "@aws-cdk/aws-dynamodb";

As I write const dynamodbTable, copilot automatically generates the following part.

new dynamodb.Table(this, "dynamodbTable", {

So it only instantiates the table using the packages I provided. However, as I go to the next line to provide the partition key and other settings for the table, it surprisingly suggested the following code:

partitionKey: { name: "id", type: dynamodb.AttributeType.STRING },
billingMode: BillingMode.PAY_PER_REQUEST,
removalPolicy: RemovalPolicy.DESTROY,

Regarding the lambda functions, I start with the get all function. As I mentioned, it is important that you give meaningful names to your functions, because copilot will use those names to generate the code. So I only type const getAllItemsLambda, copilot generates the following for me:

  const getAllItemsLambda = new lambda.Function(this, "getAllItemsLambda", {
    runtime: lambda.Runtime.NODEJS_12_X,
    code: lambda.Code.fromAsset("lambda"),
    handler: "getAllItems.handler",
    environment: {
      TABLE_NAME: dynamodbTable.tableName,
    },
  });

Very nice so far, regarding the IAM Roles for our lambdas, as I start the name of the db, I get the following suggestions:

  dynamodbTable.grantReadWriteData(createItemsLambda);
  dynamodbTable.grantReadWriteData(getAllItemsLambda);

This is nice, though, it doesn't respect the principal of least privilege. so I amend the second line to grantReadData.

Now let's go for the API Gateway. As I start typing api, I get the following suggestion:

const api = = new apigateway.RestApi(this, "restApi", {
    restApiName: "cdkwithcopilot",
  });

I also get the following suggestions as I type the name of the resource:

  const root = api.root;
  const getAllItemsApi = new apigateway.LambdaIntegration(getAllItemsLambda);
  root.addMethod("GET", getAllItemsApi);

  const createItemsApi = new apigateway.LambdaIntegration(createItemsLambda);
  root.addMethod("POST", createItemsApi);

All the resources were suggested as expected, only for the usage plan, copilot wrongly suggested api.UsagePlane instead of api.addUsagePlan . Also, it had a little problem when I added the Api Key.

Getting to the lambda functions, I was able to generate the following using copilot:

    const AWS = require('aws-sdk');
    const db = new AWS.DynamoDB.DocumentClient();
    const TablName = process.env.TABLE_NAME;

    export const handler = async (event: any = {}): Promise<any> => {
        const params = {
            TableName: TablName
        };
        const result = await db.scan(params).promise();
        return result.Items;
    }

Also for the other lambda function, which creates the items:

    const AWS = require('aws-sdk');
    const db = new AWS.DynamoDB.DocumentClient();
    const TABLE_NAME = process.env.TABLE_NAME || ''; //added manually

    export const handler = async (event: any = {}): Promise<any> => {

        const params = {
            TableName: TABLE_NAME
        };
        try{
            const response = await db.scan(params).promise();
            return {status: 'success', data: response.Items};
        }
        catch(dbError){
            return{status: 'error', data: dbError};
        }
    };

Now the moment of truth: CDK synth
And worked as expected. I was truly amazed by how powerful copilot is. I even wrote a few lines of this blog post with it!
Arguably copilot is not a replacement for developers, but an amazing tool which helps us (developers) build better software.
I hope you enjoyed this post.
Thank you very much for reading.
Pedram and Copilot

BASIC AWS CDK Backend API

Pedram Hamidehkhan — Wed, 14 Jul 2021 19:14:00 +0000

In this post, you learn how to use AWS CDK to create a basic yet powerful backend in AWS. The components used for this application are, AWS API Gateway which receives http requests as an entrance to our application, AWS Lambda where we implement our business logic, Dynamodb a NoSQL Database where we store our data.

First thing's first, let's initialize an empty CDK typescript project:
cdk init app --language=typescript.

Then we go to package.json to declare the dependencies for our project.
Add the following modulesto the dependencies:

"@aws-cdk/core": "*",
"@aws-cdk/aws-apigateway": "*",,
"@aws-cdk/aws-lambda": "*",,
"@aws-cdk/aws-dynamodb": "*",

This is an optional step, but go ahead and run "npm install" in the root directory of your project. This will download the dependencies and give you intellisense which comes very handy.
The go to the lib folder and the typescript file for your application stack.

Add the following import statements to before class declaration:

import cdk = require("@aws-cdk/core");
import apigateway = require("@aws-cdk/aws-apigateway");
import dynamodb = require("@aws-cdk/aws-dynamodb");
import lambda = require("@aws-cdk/aws-lambda");
import { RemovalPolicy } from "@aws-cdk/core";
import { create } from "domain";
import { BillingMode } from "@aws-cdk/aws-dynamodb";

In order to create our database, add the following:

const dynamoTable=new dynamodb.Table(this,'mytestDB',{
  partitionKey:{
    name:'itemId',
    type:dynamodb.AttributeType.STRING
  },
    removalPolicy:RemovalPolicy.RETAIN
});

Here we defined a partition key 'itemId' of type string, and the removal policy of our database. As data is very sensitive (of course, not for this demo but in real life), we chose the Retain policy if our stack gets destroyed. You could also chose Snapshot, or destory policy if you like.
Getting to the business logic of our application, we declare our lambda functions.
Firstly, we create a get all function, which returns everything in the databse.

const getAll = new lambda.Function(this, 'getAllitems',{
  code: new lambda.AssetCode('./src'),
  handler:'get-all.handler',
  runtime:lambda.Runtime.NODEJS_10_X,
  environment:{
    TABLE_NAME: dynamoTable.tableName,
    PRIMARY_KEY:'itemId'
  }
});

Firstly, we tell cdk where the code for our function is, (src folder), then the handler inside that code, the runtime and some environment variables where we pass in our dynamodb table name and the pratition key.

Than we add one more lambda function which creates item in our databse as follows.

const createLambda = new lambda.Function(this, 'createItem',{
  code: new lambda.AssetCode('./src'),
  handler:'create.handler',
  runtime:lambda.Runtime.NODEJS_10_X,
  environment:{
    TABLE_NAME: dynamoTable.tableName,
    PRIMARY_KEY:'itemId'
  },
});

As of now, our lambdas cannot connect to the database, as the IAM role for them is not yet created. Using the following command, we grant access to our lambdas, while respecting the prinicple of least privilege.

dynamoTable.grantReadData(getAll);
dynamoTable.grantReadWriteData(createLambda);

Having created our persistance layer and our business logic layer, we go ahead and create the gateway to our application. As we would like to serve our content via REST API, we declare an REST API gateway as follows:

const api = new apigateway.RestApi(this,' testApi',{
  restApiName:'my test api'
});

Then we create a root API on this API Gateway. When a request hits this 'root' api, they can get all items in our db. Declaring the api is not sufficient, we need to connect it with our lambda. for that we use the
LambdaIntegration method of the api gateway. API gateway has many integration types that are worth looking.

const rootApi=api.root.addResource('root');
const getAllApi=new apigateway.LambdaIntegration(getAll);
rootApi.addMethod('GET',getAllApi);

Using the following code we can also create items in our databse. As the Create item in database translates to POST in REST, we add this functionality on POST method of our API.

const createApi=rootApi.addResource('create');
const createApiIntegration=new apigateway.LambdaIntegration(createLambda);
createApi.addMethod('POST', createApiIntegration);

As we are security concious developers, we don't provide apis without auhtentication in the wild internet. Using the follwing code, we add throttling to our api, which means that our costs won't skyrocket unexpectedly. We also add an apikey to our api gateway. This is, of course, a very basic authentication mechanism, but for the purpose of this demo is sufficient. For production grade applications you might want to have a look at AWS Cognito.

const plan = api.addUsagePlan('UsagePlan', {
  name:'EASY',
  throttle:{
    rateLimit:20,
    burstLimit:2
  }
});
const key =api.addApiKey('ApiKey');
plan.addApiKey(key);

Now we get to the actual code of our lambda functions. Inside the root folder, create a folder called 'src'. Then create a file called 'create.ts'.

Add the follwing to create.ts

const AWS = require('aws-sdk');
const db = new AWS.DynamoDB.DocumentClient();
const TABLE_NAME = process.env.TABLE_NAME || '';
const PRIMARY_KEY = process.env.PRIMARY_KEY || '';
export const handler = async (event: any={}) : Promise <any> => {

   const item =typeof event.body == 'object' ? event.body :JSON.parse(event.body);
   const ID = String.fromCharCode(65 + Math.floor(Math.random()*26));
   item[PRIMARY_KEY] = ID;
    const params = {
        TableName: TABLE_NAME,
        Item:item
    };

  try {
    await db.put(params).promise();
    return { statusCode: 200, body: 'success' };
  } catch (dbError) {
    return { statusCode: 500, body: JSON.stringify(dbError)};
  }
};

The important part of this code is the ID. Dynamodb is designed differently from traditional relational dbs, and therefore you cannot have an identity field which is incremented by the db. You have to provide a unique ID when you insert items in your db.

Having declared our create function, we then create our get all function. Add a file called get-all.ts and add the following to it.

const AWS = require('aws-sdk');
const db = new AWS.DynamoDB.DocumentClient();
const TABLE_NAME = process.env.TABLE_NAME || '';

export const handler = async () : Promise <any> => {

  const params = {
    TableName: TABLE_NAME
  };

  try {
    const response = await db.scan(params).promise();
    return { statusCode: 200, body: JSON.stringify(response.Items) };
  } catch (dbError) {
    return { statusCode: 500, body: JSON.stringify(dbError)};
  }
};

Now we are ready to verify our cdk stack. First run 'npm run build' which compiles typescript to javascript.
Then run cdk synth. This should give a cloud formation template. If it returns an error, go to previous steps and verify your work.
Before you can deploy this applicaion, you need to bootsrap your environment. To do that, run the following.

cdk bootstrap aws://youraccountID/yourregion

set CDK_NEW_BOOTSTRAP=1
cdk bootstrap aws://youraccountID/yourregion

Now you are ready to deploy your cdk app.

cdk deploy

Some more useful cdk commands:

cdk ls //lists the stacks in your application
cdk diff //shows the difference of your current deployed stack and your local stack
cdk doctor //*kind of* verifies your cdk stack for warnings

That is it for a very minimal backend in aws. Of course, you can add more functions, to do update and delete. But as they are very similar, they are left out in this demo.

The source code on github: https://github.com/pedramha/cdk-crudsample

The link to this video can be found at:

Part1: https://www.youtube.com/watch?v=uhE3Z2lGGXQ

Part2: https://www.youtube.com/watch?v=5oKEti1W5BQ