The Ops Community ⚙️: David

Building an URL Shortener with Github Actions, Serverless Framework, and AWS Function Urls

David — Fri, 03 Jun 2022 14:58:09 +0000

What is a URL Shortener?

It is a tool that randomly assigns a set of numbers and characters to the URL you enter, considerably reducing its original length.

This article aims to create this tool while achieving as much automation as possible during development and demonstrate the use case of some AWS services.

Walkthrough

Let's start by creating a package.json with:

npm init

Next, let's add the necessary dependencies to create a lambda using typescript.

  "dependencies": {
    "@types/aws-lambda": "^8.10.95",
    "serverless": "^3.15.2",
    "serverless-plugin-typescript": "^2.1.2",
    "typescript": "^4.6.3"
  }

Don't forget to install these newly added dependencies with:

npm i

Now let's create a serverless.yml file where we will define our AWS resources as Infrastructure as Code. If you want to learn more about Serverless Framework.

service: url-shortener

plugins:
  - serverless-plugin-typescript

provider:
  name: aws
  runtime: nodejs14.x
  stage: dev

functions:
  hello:
    handler: handler.hello
    events:
      - http:
          path: /
          method: get

Create a file named handler.ts, with this boilerplate code to make a hello world lambda.

import { Handler } from 'aws-lambda';

export const hello: Handler = (event: any) => {
  const response = {
    statusCode: 200,
    body: JSON.stringify(
      {
        message: 'Go Serverless v1.0! Your function executed successfully!',
        input: event,
      },
      null,
      2
    ),
  };

  return new Promise((resolve) => {
    resolve(response)
  })
}

Is time to push our code into our repository.

git add .
git commit -m "Create boilerplate lambda"
git push

Now we can start testing our lambda if we configure our AWS credentials with aws configure and deploy our code with the command serverless deploy, but before we do that, let's automate this process using Github Actions.

GitHub Actions makes it easy to automate all your software workflows with Continuous Integration and Continuous Delivery. Build, test, and deploy your code right from GitHub.

In our Github repository, click Settings on the left bar side, select Secrets then Actions. In the Actions secrets window, select New repository secret.

Create two secrets named AWS_KEY and AWS_SECRET, respectively. Here we will add our AWS Access Key ID and Secret Access Key. If you want to learn how to obtain these values, check this documentation.

Select Actions on the upper bar, in the Actions screen, select Set up a workflow yourself.

Clear the pre-defined template and add the following snippet. This snippet will use our previously defined secrets to authenticate and configure the necessary environment to deploy our resources into AWS.

name: Dev
on:
  push:
    branches:
      - main
jobs:
  deploy-dev:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - uses: actions/setup-node@v1
      with:
        node-version: '14.x'
    - name: Install Serverless Framework
      run: npm install -g serverless
    - name: Serverless AWS authentication
      run: sls config credentials --provider aws --key ${{ secrets.AWS_KEY }} --secret ${{ secrets.AWS_SECRET }}
    - name: Install NPM dependencies
      run: npm install
    - name: Deploy Lambda functions
      run: sls deploy

Name the file whatever you want, commit and push. Be sure to git fetch and git pull this file into your local repository. The next time we make some change in our code, it will trigger a deployment pipeline which will create our lambda in AWS.

❗ Note: If Actions won't activate, check the branch specified in:
on:
  push:
    branches:
      - master

After the pipeline finishes deploying successfullya, let's check our newly created resource in AWS.

Hello Lambda in AWS

Since our CI/CD integration is working correctly, let's start coding our URL-shortener solution. First, we need to create three variables that will help us define the name of our bucket, a domain, and the name of our application. For this example, I'm going to use the following values:

/dev/url-shortener/APPLICATION_NAME : url-shortener
/dev/url-shortener/DOMAIN : http://<<add your domain here or s3 endpoint>>/
/dev/url-shortener/S3_NAME : <<add your domain or name here>>

You can add any domain that you want; for the sake of the example, I will use a Route 53 domain that I had registered. If you don't have a domain, you can use the S3 endpoint of the bucket that we will create as the value for the variable DOMAIN. For the S3_NAME variable, you can also write any name. However, I will use the domain's name to register the s3 endpoint of this bucket under Route 53 as an Alias Record. For the value of the variable APPLICATION_NAME, name it the same as you defined in the service field of the serverless.yml file.

Now we proceed to modify our serverless.yml, where we are going to create a DynamoDB table named atomic_counter , an S3 Bucketwith some rules, some iam roles to give our lambda access to these resources, and we are going to change our hello lambda that used ApiGateway to a Function Url.

Let's define our added Parameter Store variables to use in our code. You can define the region where your variables are located. In this example, our variables are in us-east-1. The variable value should read as:

${ssm:/${self:provider.stage}/${self:service}/DOMAIN}
${ssm:/dev/url-shortener/DOMAIN}

As we reference, some of these values on the same serverless.yml file.

  environment:
    DYNAMO_ATOMIC: ${self:resources.Resources.atomicCounter.Properties.TableName}
    DOMAIN: ${ssm:/${self:provider.stage}/${self:service}/DOMAIN}
    APPLICATION_NAME: ${ssm:/${self:provider.stage}/${self:service}/APPLICATION_NAME}
    S3_NAME: ${ssm:/${self:provider.stage}/${self:service}/S3_NAME}

Change the handler and the event of our lambda to type url, which will create an http endpoint with a url that we can use to send a POST with the information that we need to process. You can custom the cross-origin resource sharing to whatever suits your needs.

Using Function URLs suits our use case since we don't need to create a complex REST API. We only need an HTTP endpoint that we can use in a front-end view.

functions:
  shortUrl:
    handler: handler.short
    url: 
      cors: true

Next, create a DynamoDB table that will be used as an atomic counter and set an index called name.

resources:
  Resources:
    atomicCounter:
      Type: "AWS::DynamoDB::Table"
      Properties:
        TableName: atomic_counter
        AttributeDefinitions:
          - AttributeName: name
            AttributeType: S
        KeySchema:
          - AttributeName: name
            KeyType: HASH
        BillingMode: PAY_PER_REQUEST
        StreamSpecification:
          StreamViewType: NEW_AND_OLD_IMAGES

Create an S3 bucket, which will have public access, and it will serve as a static website host. We also will need a Lifecycle rule as our service will work as a redirection of the objects we will create in our bucket. We would like to expire old links that we no longer use.

    page:
      Type: AWS::S3::Bucket
      Properties:
        AccessControl: PublicRead
        BucketName: ${self:provider.environment.S3_NAME}
        WebsiteConfiguration:
          IndexDocument: index.html
        LifecycleConfiguration:
          Rules:
            -
              ExpirationInDays: 5
              Prefix: '/'
              Status: Enabled

Finally, let's give access to our lambda through IAM policies, these policies will provide access to put and update data into our s3 bucket and dynamo table.

service: url-shortener

plugins:
  - serverless-plugin-typescript

provider:
  name: aws
  runtime: nodejs14.x
  stage: dev
  environment:
    DYNAMO_ATOMIC: ${self:resources.Resources.atomicCounter.Properties.TableName}
    DOMAIN: ${ssm:/${self:provider.stage}/${self:service}/DOMAIN}
    APPLICATION_NAME: ${ssm:/${self:provider.stage}/${self:service}/APPLICATION_NAME}
    S3_NAME: ${ssm:/${self:provider.stage}/${self:service}/S3_NAME}
  iamRoleStatements:
    - Effect: "Allow"
      Action:
        - dynamodb:UpdateItem
        - logs:CreateLogGroup
        - logs:CreateLogStream
        - logs:PutLogEvents
      Resource:
        - "Fn::GetAtt":
            - atomicCounter
            - Arn
    - Effect: "Allow"
      Action:
        - s3:PutObject
        - s3:PutObjectAcl
      Resource: "arn:aws:s3:::${self:provider.environment.S3_NAME}/*"
functions:
  shortUrl:
    handler: handler.short
    url: 
      cors: true
resources:
  Resources:
    atomicCounter:
      Type: "AWS::DynamoDB::Table"
      Properties:
        TableName: atomic_counter
        AttributeDefinitions:
          - AttributeName: name
            AttributeType: S
        KeySchema:
          - AttributeName: name
            KeyType: HASH
        BillingMode: PAY_PER_REQUEST
        StreamSpecification:
          StreamViewType: NEW_AND_OLD_IMAGES
    page:
      Type: AWS::S3::Bucket
      Properties:
        AccessControl: PublicRead
        BucketName: ${self:provider.environment.S3_NAME}
        WebsiteConfiguration:
          IndexDocument: index.html
        LifecycleConfiguration:
          Rules:
            -
              ExpirationInDays: 5
              Prefix: '/'
              Status: Enabled

In our handler.ts, we need to check the original inbound URL with a regex function. If the given URL doesn't have a prefix, we append the string http://. Otherwise, the WebsiteRedirectLocation function will throw an error. Next, we get the number in the DynamoDB counter, which we will encode into a shortened string. We write a zero-length file out to our S3 bucket with the appropriate metadata that will serve as a path that redirects to the desired URL. Lastly, we return the shortened URL.

import { Handler } from 'aws-lambda';
import { v4 as generator } from 'uuid';
import * as AWS from 'aws-sdk';

const s3 = new AWS.S3();
const dynamodb = new AWS.DynamoDB();

let shortName = function(counter: number): string{
    const base62: string = generator();
    const base62Length: number = base62.length;
    let shortName: string = '';

    while (counter) {
        let leftOver: number = counter % base62Length;
        counter = Math.floor(counter / base62Length);
        shortName = base62[leftOver].toString() + shortName;
    }

    return shortName;
}

let addHttpPrefix = function (url:string): string{
  if (!/^https?:\/\/(.*)/i.test(url)) {
      url = "http://" + url;
  }
  return url;
}

export const short: Handler = (event: any, context: any) => {

    let body: any = JSON.parse(event.body)
    let dynamoParams: any = {
        Key: {
            'name': {
                S: `${process.env.APPLICATION_NAME}`,
            }
        },
        TableName: `${process.env.DYNAMO_ATOMIC}`,
        UpdateExpression: 'SET counterValue = counterValue  + :increment',
        ExpressionAttributeValues: {
            ":increment": { N: "1" }
        },
        ReturnValues: "ALL_NEW"
    };

    dynamodb.updateItem(dynamoParams, function (err, data) {
        if (err) context.fail(err, err.stack);
        else {
            let s3Params = {
                Bucket: `${process.env.S3_NAME}`,
                Key: shortName(Number(data.Attributes.counterValue.N)),
                ACL: 'public-read',
                Body: '',
                ContentType: 'text/html',
                WebsiteRedirectLocation: addHttpPrefix(body.url)
            };

            s3.putObject(s3Params, function (err) {
                if (err) context.fail(err, err.stack);
                else
                    context.succeed({ "shortUrl": `${process.env.DOMAIN}` + s3Params.Key });
            });

        }

    });
}

Before we push and deploy these resources, let's update our package.json, with some libraries, like uuid, which will create a string with base62, to randomize the created URL.

  "dependencies": {
    "@types/aws-lambda": "^8.10.95",
    "@types/node": "^17.0.29",
    "aws-lambda": "^1.0.7",
    "serverless": "^3.15.2",
    "serverless-plugin-typescript": "^2.1.2",
    "typescript": "^4.6.3",
    "uuid": "^8.3.2"
  },

After our actions pipeline finishes deploying, create a register in the atomic_counter table with the value of 1 and the application's name, which we will use as an encoded string.

{
  "name": {
    "S": "url-shortener"
  },
  "counterValue":{
    "N": "1"
  }
}

Let's wrap up by creating an alias record of our s3 endpoint in Route 53, which will be used as a domain response of our url-shortener service.

Test our endpoint, by sending an URL that we like to short, and voilà! we completed our url-shortener.

You can find the complete code here. I hope you find this article helpful.

How to save up on AWS S3 Buckets while deploying with serverless framework

David — Fri, 03 Jun 2022 14:56:07 +0000

The Problem:

When deploying one or several services through serverless framework, it creates a bucket similar to this: <<your-service-name>>-<<stage>>-serverlessdeploymentbucket-12i2nulwb47go, which contains the cloudformation template of the resources we have created, the zipped code, and a serverless-state.json file.

At first, this might not be a problem, except when we manage several services and several environments (e.g: dev,qa,stg), which can exceed the default limit of 100 buckets or even the hard cap limit of 1000 buckets very easily, besides being complicated to manage them in case you no longer use a service and want to delete it.

How do we solve this?

Serverless framework lets you define a predefined bucket, which will help us centralize every other serverless deployment bucket into one. The plugin is skilled enough to separate our services into different stages as prefixes.

Let's start by creating an S3 bucket and a Parameter store with the bucket's name as a value.

Note: I will use aws cdk to create these resources; feel free to skip this part. If you want to learn more about cdk or how to use it, I recommend following this CDK Workshop

Create a bucket that will be used to centralize our serverless deployments. Set public read access as false and versioning as false (if you like you can also enable it, but that will create different versions of objects for every deployment which might not be recommended).

Create a Parameter Store which will have as a value the name of our Bucket; this will help us define the Bucket's name in our serverless.yml programmatically as we can use a value name with a variable in another region.

In our serverless.yml, we add these lines, which will indicate the bucket in which our code resides, referencing the variable we created.

Note: In most cases we don't need to install or add the serverless-deployment-bucket plugin

provider:
  name: aws
  runtime: go1.x
  stage: dev
  region: us-east-1
  deploymentBucket:
    name: ${ssm(us-east-1):/GLOBAL/DEPLOYMENT_BUCKET}

After deploying our service, we noticed that two prefixes were created, which refer to the DEV and QA environments, saving us two buckets in one.

However, what if we have different services in different regions? In this case, the buckets need to be in the same region as our services; otherwise, we would see this error.

To solve this, we need to create a bucket in the same region as our services and create another Parameter Store that will refer to that bucket's name.

Reference: Serverless Deployment Bucket

How to save up on AWS Parameter Store with serverless framework

David — Fri, 03 Jun 2022 14:55:18 +0000

The Problem:

It is a bad practice and even a security risk to use hard-coded values within our code that reference an API Key or a Database Password. Alternatively, we can have values that can change over time because of a business decision or an unforeseen situation; this will mean that we have to change our code every time a value needs to be changed. For this, we can use the AWS Systems Manager service called Parameter Store.

Parameter Store is a capability of AWS Systems Manager that provides secure, hierarchical storage for configuration data management and secrets management. We can store data such as passwords, database strings, Amazon Machine Image (AMI) IDs, and license codes as parameter values. We can store values as plain text or encrypted data.

However, what happens when we have to use several variables? It is difficult to maintain them, but the problem doubles with several development environments. We can easily reach the hard cap limit of 10,000 standard parameters per account and region.

How do we solve this?

We can save several parameter stores; if we start writing them in JSON format, we can have them organized in a clear and organized way.

Let us start creating a Parameter Store with our JSON values. I will use my first and last name as values for this example.

/dev/myapp/INFO >> {"firstName":"David","lastName":"Llerena"}

Create a Typescript serverless Lambda Project with serverless framework. Let's add the following dependencies:

//package.json
{
  "name": "myapp",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "dependencies": {
    "aws-sdk": "2.952.0",
    "@types/aws-lambda": "^8.10.95",
    "serverless": "^3.15.2",
    "serverless-plugin-typescript": "^2.1.2",
    "typescript": "^4.6.3"
  },
  "author": "",
  "license": "ISC"
}

Now let's create some javascript code in a file named helperScript.js, Create a function that will call SSM service and read a Parameter store which we would like to parse and read each value of the JSON values. ResolveConfigurationProperty statement will reference the stage and name of our service, declared in our serverless.yml file.

//helperScript.js
const SSM = require("aws-sdk/clients/ssm");

module.exports.getParameters = async ({ resolveConfigurationProperty }) => {
  const prefix = await resolveConfigurationProperty(["custom", "prefix"]);
  const region = await resolveConfigurationProperty(["provider", "region"]);
  const ssm = new SSM({ region });
  const policy = await ssm
    .getParameter({
      Name: prefix + "/INFO",
      WithDecryption: true,
    })
    .promise();
  const res = JSON.parse(policy.Parameter.Value);
  return {
    firstName: res.firstName,
    lastName: res.lastName

  };
};

In our serverles.yml file, we will reference this helperScript.js to call the variables used in our code under the environment statement. Give the lambda the necessary permissions to access the SSM service. It is recommended only to give access to the resources we are using.

If we are using a serverless version minor to version 3, we have to add this statement variablesResolutionMode: 20210326 under service declaration

#serverless.yml
service: myapp

plugins:
  - serverless-plugin-typescript

provider:
  name: aws
  runtime: nodejs16.x
  stage: dev
  region: us-east-1
  environment:
    FIRST_NAME: ${file(./helperScript.js):getParameters.firstName}
    LAST_NAME: ${file(./helperScript.js):getParameters.lastName} 
  iamRoleStatements:
    - Effect: "Allow"
      Action:
        - ssm:GetParameter
        - ssm:GetParameters
        - ssm:GetParametersByPath
      Resource: "*"
custom:
  prefix: /${self:provider.stage}/${self:service}
functions:
  hello:
    handler: handler.hello

Finally, let's use this Parameter Store in our lambda code.

//handler.ts
import { Handler } from 'aws-lambda';

export const hello: Handler = (event: any) => {
  const response = {
    statusCode: 200,
    body: JSON.stringify(
      {
        message: 'My First name is '+`${process.env.FIRST_NAME}`+' and my last name is '+`${process.env.LAST_NAME}`
      },
      null,
      2
    ),
  };

  return new Promise((resolve) => {
    resolve(response)
  })
}

And that's it!, if we execute our lambda it should look like this:

This will surely help us save up some Parameter Stores and keep them neat and clean. However, we should consider the size that these variables could get. We might take into consideration the use of Advanced Parameters.

Reference: Serverless Framework Variables

Creating a temperature calculator with TravisCI, CDK,Rust, and AWS Lambda/Function URLs

David — Fri, 03 Jun 2022 14:52:35 +0000

We will create a tool that calculates the equivalent temperature values across several commonly used temperature scales.

This article aims to create a temperature calculator written in Rust, which we will expose as a URL endpoint through Function Urls characteristic of AWS Lambda. We will try to automate these resources with CDK and Travis CI for CI/CD deployments.

Requirements

AWS account
NPM / CDK / TypeScript / Nodejs
Rust (cargo)
Travis CI account
Docker (optional)

Walkthrough

Configure our AWS credentials with aws configure. Create a typescript project with cdk, run:

cdk init rust-app --language typescript

At the root of our project, create a folder named lambda and another folder called temperature; inside this folder, create a file named main.rs and a file named Cargo.toml.

In our Cargo.toml, we will define our dependencies.

[package]
name = "rust-lambda-temperature"
version = "0.1.0"
edition = "2021"
authors = ["david"]
autobins = false

[dependencies]
lambda_runtime = "0.5.1"
log = "0.4.17"
serde_json = "1.0.81"
simple_logger = "2.1.0"
tokio = {version = "1.18.2", features = ["full"]}

[[bin]]
name = "bootstrap"
path = "src/main.rs"

In main.rs file we will define our code in rust, we will expect the scale and temperature value we would like to convert.

In our CDK stack code, we will create a rust lambda that will use the arm64 architecture and will be exposed as a Function URL. Because AWS Lambda does not currently support the arm64 runtime in rust, we will use a custom runtime provided.al2. It is essential to specify the compiled code as a bootstrap binary. You can find more information about it here.

#rust-stack.ts
import { Duration, Stack, StackProps } from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import { Construct } from 'constructs';

export class RustStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    let fn = new lambda.Function(this, 'LambdaRustStack', {
      code: lambda.Code.fromAsset(
        'lambda/target/aarch64-unknown-linux-gnu/release/lambda'
      ),
      functionName: "temperature-calculator-dev",
      handler: 'main',
      memorySize: 1024,
      environment: {
        RUST_BACKTRACE: '1',
      },
      runtime: lambda.Runtime.PROVIDED_AL2,
      architecture: lambda.Architecture.ARM_64,
      timeout: Duration.seconds(300),
    });

    fn.addFunctionUrl({
      authType: lambda.FunctionUrlAuthType.NONE,
    });
  }
}

Before building our code with cargo build, we must compile it to work on arm64architectures. We will use the cross library, which will allow us to make cross compilations to different architectures without affecting system installation. You can read more about cross-compilation here and about the library here.

Install the library with cargo install cross, change directories to where our Cargo.toml file is and run cross build --target aarch64-unknown-linux-gnu --release; this will create some files and our binary bootstrapfile. If you like, create an additional folder inside target/aarch64-unknown-linux-gnu/release directory named lambda; here, execute cp bootstrap lambda, which we reference in our code: lambda.Code.fromAsset section of our lambda, we previously defined in our CDK stack.

Now we have almost everything set to deploy our lambda into AWS. Run

cdk bootstrap

To create the necessary IAM Roles, to deploy our code through CDK. And then run

cdk deploy

To deploy our code into AWS.

And that's it! We learned how to deploy an arm64 Rust Lambda into AWS with CDK. Now, let's automatize the deployment process with Travis CI.

What is Travis CI?

Travis CI is a continuous integration tool that quickly tests and deploys your projects. Let you sync your build projects within minutes from different sources like Github, Bitbucket, and Gitlab.

Create a file named .travis.ymlin the root of our project.

Our build specification will define our AWS credentials; for CDK to create resources into AWS, we will use a rust language image. However, as CDK uses Nodejs/Typescript, we need to update the native version of Nodejs in this image with nvm. Finally, we will use crosscommand to compile our code and CDK to push our code into AWS.

Note: If done previously consider removing the cdk bootstrap line

env:
  global:
    - AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID}
    - AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY}
jobs:
  include:
    - language: rust
      script: echo "npm test temporarily disabled"
      before_install:
        - sudo wget https://raw.githubusercontent.com/creationix/nvm/v0.33.8/install.sh -O ~/.nvm/nvm.sh
        - source ~/.nvm/nvm.sh
        - . "$NVM_DIR/nvm.sh"
        - nvm install 14.5.0  
        - node --version
        - npm i -g typescript
        - npm install -g aws-cdk
        - npm i
        - curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
        - unzip awscliv2.zip
        - sudo ./aws/install
        - aws --version
      before_script:
        - cd lambda
        - cargo install cross
        - cross build --target aarch64-unknown-linux-gnu --release
        - cd target/aarch64-unknown-linux-gnu/release
        - mkdir lambda
        - cp bootstrap lambda
        - ls
        - cd lambda
        - ls
        - cd ../../../../../
        - ls
        - mkdir ~/.aws/
        - touch ~/.aws/credentials
        - echo -e "[default]\n $AWS_ACCESS_KEY_ID \n $AWS_SECRET_ACCESS_KEY \n region=us-east-1" >> ~/.aws/credentials
        - cdk bootstrap
        - cdk deploy --require-approval never

In Travis CI dashboard, be sure to give enough permissions for travis to see and manage the repository.

Here we will add our AWS credentials as secrets, hit View Config, More Options and then Settings, in the Environment section add your credentials, be sure to check any spelling error, it should be the same as the env section in our .travis.ymlfile.

That's it now any change we make on our repository will be reflected in our lambda in AWS.

You can check the complete code here.

I hope you have learned something new with this tutorial!

Making a WhatsApp Crypto Chatbot with AWS Lex, CDK, CoinMarketCap, and Twilio

David — Wed, 01 Jun 2022 20:37:33 +0000

What is a Chatbot?

A chatbot is a software or computer program that simulates human conversation or "chatter" through text or voice interactions.

Amazon Lex is a fully managed artificial intelligence (AI) service with advanced natural language models to design, build, test, and deploy conversational interfaces in applications.

This article aims to create an automated agent that will retrieve information about the current prices and trends of the crypto market.

Requirements

AWS account
NPM / CDK / Python
Coinmarketcap API key
Twilio account (optional)

Walkthrough

Let's create an account in CoinMarketCap to get our API Key. Feel free to choose the plan that adjusts to your use case, but the basic plan is good enough for this example.

With our API Key, create a Parameter Store to store this value.

/dev/crypto-bot/COIN_MARKETCAP_API_KEY : <<your-api-key>>

For this example, I will use a clear string for the API Key value, but it is recommended to secure the string with an encrypted AWS KMS key.

Now lets begin creating our project with cdk, after we configure our aws credentials, run:

cdk init sample-app --language python

In our requirements.txt file lets add the following dependencies:

#requirements.txt
aws-cdk-lib==2.23.0
constructs>=10.0.0,<11.0.0
python-coinmarketcap==0.3
requests==2.27.1
boto3>=1.15.0

python-coinmarketcap is a dependency that wraps Coinmarketcap API very nicely; feel free to use this dependency or to use a direct implementation which you can find here.
boto3 is a dependency that acts as the AWS SDK for Python; this will be used to access the Parameter Store previously created.

In our app.py file you can change the name of the project and the name of the stack, for this example I will name it cbot.

#app.py
import aws_cdk as cdk

from cbot.cbot_stack import CbotStack


app = cdk.App()
CbotStack(app, "cbot")

app.synth()

Create a folder with the name of your project (cbot), and create or rename the name of the stack file (cbot_stack.py). In this stack, we will create a lambda, give that lambda access to our Parameter Store, and create a layer to add our dependencies.

Create a folder named lambda, and create a cbot_handler.py. In this lambda, we will use the CoinMarketCap API, which will interact with our slot intent.

#cbot_handler.py
def search_crypto(intent_request):
    session_attributes = get_session_attributes(intent_request)
    slots = get_slots(intent_request)
    crypto = get_slot(intent_request, "crypto")
    api_key = ssm.get_parameter(Name="/dev/crypto-bot/COIN_MARKETCAP_API_KEY")
    cmc = coinmarketcapapi.CoinMarketCapAPI(api_key["Parameter"]["Value"])
    r = cmc.cryptocurrency_info(symbol=crypto.upper())
    text = repr(r.data[crypto]["description"])
    message = {"contentType": "PlainText", "content": text}
    fulfillment_state = "Fulfilled"
    return close(intent_request, session_attributes, fulfillment_state, message)

Our project should look a bit like this:

Run the cdk bootstrap command to prepare our account to handle cdk deployments.

cdk bootstrap

Now we are ready to deploy our lambda into our account

cdk deploy

Let's start with the final step, create a bot using the AWS Lex service

Creation method > Create a blank bot
Bot configuration > Name your bot
IAM permissions > Create a role with basic Amazon Lex permissions
Children’s Online Privacy Protection Act (COPPA) > No
Language > English (US)

Create a Welcome Intent; let's add some examples that our bot will learn and detect our intent

Add our bot response to the fulfillment section

Test our bot, if we configure our intents properly it should response with our fulfillment text

Configure the text of the fallback intent, if something goes wrong this intent should catch this error and show a generic error message

Save the intent, build and test. If you write something that we didn't add to the utterance examples, it should trigger our fallback intent.

Create another intent named CryptoSearch; let's add some utterance examples to detect if a user wants to search about crypto

Add a slot. In this slot, we will capture the crypto symbol we would like to search with our CoinMarketCap API; you can define a specific type of data, but for simplicity, I will use the integrated type AMAZON.FirstName to capture the value inputed by the user. (Be sure to name it identical to our code in our lambda.)

Under Deployment in Aliases, let's add our lambda, be sure to create a production alias when you move your bot to production. For this example, we will use the default alias

In the fulfillment section of our CryptoSearch intent, be sure to use our lambda function

Save the intent, build and test our bot. Now we can retrieve information about any crypto that CoinMarketCap supports! We can even try fancy things like plotting, creating trends, or showing candle graphs.

Now let's integrate our bot into social media. In this example, I will use Twillio to publish our bot into WhatsApp, create an account in Twilio and copy the SID and Authentication values.
In AWS, lex select Channels, select Twilio and create the channel integration.

Copy the callback URL generated in our integration.

In the Twilio, dashboard, select message and set up a Twilio Sandbox for Whatsapp; here, we will copy our callback URL, which will connect the messages sent from WhatsApp to our bot in AWS Lex.

And.. that's it! Now our bot works with WhatsApp and Lex.

You can find the complete code here

The Ops Community ⚙️: David

Building an URL Shortener with Github Actions, Serverless Framework, and AWS Function Urls

What is a URL Shortener?

Walkthrough

How to save up on AWS S3 Buckets while deploying with serverless framework

The Problem:

How do we solve this?

How to save up on AWS Parameter Store with serverless framework

The Problem:

How do we solve this?

Creating a temperature calculator with TravisCI, CDK,Rust, and AWS Lambda/Function URLs

Walkthrough

What is Travis CI?

Making a WhatsApp Crypto Chatbot with AWS Lex, CDK, CoinMarketCap, and Twilio

What is a Chatbot?

Walkthrough

References: