Serverless solutions automatically scale based on demand and offer a pay-as-you-go model. This means that you only pay for the resources your application actually uses. This approach significantly reduces operational overhead, increases flexibility and accelerates development cycles, making it an attractive option for modern application development.

By abstracting server management, Serverless platforms let you concentrate on business logic and application functionality. This leads to faster deployments and more innovation. Serverless architectures are also event-driven, which means they can automatically respond to real-time events and scale to meet user demands without manual intervention.

Table of Contents

1. Important Concepts to Understand

   • Application Programming Interface (API)

   • HTTP Methods

   • Amazon API Gateway

   • Amazon DynamoDB

   • Serverless CRUD Application

   • The Serverless Framework

   • GitHub Actions

   • Postman

2. Prerequisites

3. Our Use Case

4. Tutorial Objectives

5. How to get Started:Clone the Git Repository

6. Step 1: Set up the Serverless Framework Environment

7. Step 2: Define the API in the Serverless YAML File

8. Step 3: Develop the Lambda Functions for CRUD Operations

   • Create Coffee Lambda function

   • Get Coffee Lambda function

   • Update Coffee Lambda function

   • Delete Coffee Lambda function

9. Step 4: Set Up CI/CD Pipeline Multi-stage Deployments for Dev and Prod Environments

10. Step 5: Test the Dev and Prod Pipelines

11. Step 6: Test and Validate Prod and Dev APIs using Postman

12. Conclusion

Before diving into the technical details, we'll go over some key background concepts.

Important Concepts to Understand

Application Programming Interface (API)

An Application Programming Interface (API) allows different software applications to communicate and interact with each other. It defines the methods and data formats that applications can use to request and exchange information for integration and data sharing between diverse systems.

HTTP Methods

HTTP methods or request methods are a critical component of web services and APIs. They indicate the desired action to be performed on a resource in a given request URL.

The most commonly used methods in RESTful APIs are:

• GET: used to retrieve data from a server

• POST: sends data, included in the body of the request, to create or update a resource

• PUT: updates or replaces an existing resource or creates a new resource if it doesn’t exist

• DELETE: deletes the specified data from the server.

Amazon API Gateway

Amazon API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor and secure APIs at scale. It acts as an entry point for multiple APIs, managing and controlling the interactions between clients (such as web or mobile applications) and backend services.

It also provides various functions, including request routing, security, authentication, caching and rate limiting that help simplify the management and deployment of APIs.

Amazon DynamoDB

DynamoDB is a fully managed NoSQL database service designed for high scalability, low latency, and replication of data across multiple regions.

DynamoDB stores data in a schema-less format, allowing for flexible and fast storage and retrieval of structured and semi-structured data. It is commonly used for building scalable and responsive applications in cloud-based environments.

Serverless CRUD Application

A serverless CRUD application refers to the ability to Create, Read, Update and Delete data. But the architecture and components involved differ from traditional server-based applications.

Create involves adding new entries to a DynamoDB table. The Read operation retrieves data from a DynamoDB table. Update updates existing data in DynamoDB. And the Delete operation deletes data from DynamoDB.

The Serverless Framework

The Serverless Framework is an open-source tool that simplifies the deployment and management of serverless applications across multiple cloud providers, including AWS. It abstracts away the complexity of provisioning and managing infrastructure by allowing developers to define their infrastructure as code using a YAML file.

The framework handles the deployment, scaling and updating of serverless functions, APIs and other resources.

GitHub Actions

GitHub Actions is a powerful CI/CD automation tool that allows developers to automate their software workflows directly from their GitHub repository.

With GitHub Actions, you can create custom pipelines triggered by events such as code pushes, pull requests, or branch merges. These workflows are defined in YAML files within the repository and can perform tasks like testing, building and deploying applications to various environments.

Postman

Postman is a popular collaboration platform that simplifies the process of designing, testing, and documenting APIs. It offers a user-friendly interface for developers to create and send HTTP requests, test API endpoints, and automate testing workflows.

Alright, now that you're familiar with the tools and technologies we'll use here, let's dive in.

Prerequisites

• Node.js and npm installed

• AWS CLI configured with access to your AWS account

• A Serverlesss Framework account

• Serverlesss Framework globally installed in your local CLI

Our Use Case

Meet Alyx, an entrepreneur who has recently been learning about serverless architecture. She's read about how it's a powerful and efficient way to build backends for web applications, offering a more modern approach to web application development.

She wants to apply what she's learned so far about of the fundamentals of AWS serverless  computing. She knows that serverless doesn’t mean there are no servers involved – rather, it just abstracts away the management and provisioning of servers. And now she wants to focus solely on writing code and implementing business logic.

Let’s check out how Alyx, the owner of a thriving coffee shop, begins to leverage serverless architecture for the backend of her web application.

Alyx’s Coffee Haven, an online coffee shop, offers an array of coffee blends and treats for sale. Initially, Alyx managed the shop’s orders and inventory with traditional web hosting services and operations, where she handled multiple servers and resources. But as her coffee shop grew in popularity, she started facing an increasing number of orders, especially during peak hours and seasonal promotions.

Managing the servers and ensuring the application could handle the surge in traffic became a challenge for Alyx. She found herself constantly worrying about server capacity, scalability, and the cost of maintaining the infrastructure.

She also wanted to introduce new features like personalized recommendations and loyalty programs, but this became a daunting task given the limitations of her traditional setup.

Then Alyx learned about the concept of serverless. She likened a serverless backend to a barista who automatically brews coffee in real-time, without her having to worry about the intricate details of the coffee-making process.

Excited by this idea, Alyx decided to migrate her coffee shop’s backend to a serverless platform using AWS Lambda, AWS API Gateway, and Amazon DynamoDB. This setup will let her focus more on crafting the perfect coffee blends and treats for her customers.

With serverless, each customer’s order becomes an event that triggers a series of serverless functions. Separate AWS Lambda functions processes the orders and handles all the business logic behind the scenes. For instance, it creates a customer’s order and is able to retrieve that order. It can also delete someone's order or update an order’s status.

Alyx no longer needs to worry about managing servers, as the serverless platform automatically scales up and down based on incoming order requests. Also, the cost-efficiency of serverless is huge for Alyx. With a pay-as-you-go model, she only pays for the actual compute time her functions consume, offering her a more a cost-effective solution for her growing business.

But she doesn’t stop there! She also wants to automate everything, from deploying infrastructure to updating her application whenever there’s a new change. By utilizing Infrastructure as Code (IaC) with the Serverless Framework, she can define all her infrastructure in code and manage it easily.

On top of that, she sets up GitHub Actions for continuous integration and delivery (CI/CD), so that every change she makes is automatically deployed through a pipeline, whether it’s a new feature in development or a hot fix for production.

Tutorial Objectives

• Set up the Serverless Framework environment

• Define an API in the YAML file

• Develop AWS Lambda functions to process CRUD operations

• Set up multi-stage deployments for Dev and Prod

• Test the Dev and Prod pipelines

• Test and validate Dev and Prod APIs using Postman

How to Get Started: Clone the Git Repository

To enhance your understanding and so you can follow along with this tutorial more effectively, go ahead and clone the project’s repository from my GitHub. You can do that by going here. As we move forward, feel free to edit the files as you feel necessary.

After cloning the repository, you will notice the presence of multiple files in your folder, as you can see in the image below. We’ll use all of these files to build our serverless coffee shop API.

Step 1: Set up the Serverless Framework Environment

To set up the Serverless Framework environment for automated deployments, you'll need to authenticate your Serverless Framework account via the CLI.

This requires creating an access key that enables the CI/CD pipeline and utilizes the Serverless Framework to authenticate securely into your account without exposing your credentials. By signing into your Serverless account and generating an access key, the pipeline can deploy your serverless application automatically from the build configuration file.

To do this, head to your Serverless account and navigate to the Access Keys section. Click on “+add,” name it SERVERLESS_ACCESS_KEY, and then create the key.

Once you’ve created your access key, be sure to copy and store it securely. You'll use this key as a secret variable in your GitHub repository to authenticate and authorize your CI/CD pipeline.

It will provide access to your Serverless Framework account during the deployment process. You’ll add this key to your GitHub repository’s secrets later, so your pipeline can securely use it to deploy the serverless resources without exposing sensitive information in your codebase.

Now, let’s define the AWS resources as code in the severless.yaml file.

Step 2: Define the API in the Serverless YAML File

In this file, you'll define the core infrastructure and functionality of the Coffee Shop API using the Serverless Framework’s YAML configuration.

This file defines the AWS services being utilized, including API Gateway, Lambda functions for CRUD operations, and DynamoDB for data storage.

You'll also configure an IAM role so the Lambda functions have the necessary permissions to interact with the DynamoDB service.

The API Gateway is set up with appropriate HTTP methods (POST, GET, PUT, and DELETE) to handle incoming requests and trigger the corresponding Lambda functions.

Let’s check out the code:

service: coffee-shop-api
frameworkVersion: '4'

provider:
  name: aws
  runtime: nodejs20.x
  region: us-east-1
  stage: ${opt:stage}
  iam:
    role:
      statements:
        - Effect: Allow
          Action:
            - dynamodb:PutItem
            - dynamodb:GetItem
            - dynamodb:Scan
            - dynamodb:UpdateItem
            - dynamodb:DeleteItem
          Resource: arn:aws:dynamodb:${self:provider.region}:*:table/CoffeeOrders-${self:provider.stage}

functions:
  createCoffee:
    handler: createCoffee.handler
    environment:
      COFFEE_ORDERS_TABLE: CoffeeOrders-${self:provider.stage}
    events:
      - http:
          path: coffee
          method: post

  getCoffee:
    handler: getCoffee.handler
    environment:
      COFFEE_ORDERS_TABLE: CoffeeOrders-${self:provider.stage}
    events:
      - http:
          path: coffee
          method: get

  updateCoffee:
    handler: updateCoffee.handler
    environment:
      COFFEE_ORDERS_TABLE: CoffeeOrders-${self:provider.stage}
    events:
      - http:  
          path: coffee  
          method: put  

  deleteCoffee:  
    handler: deleteCoffee.handler
    environment:
      COFFEE_ORDERS_TABLE: CoffeeOrders-${self:provider.stage}
    events:
      - http:
          path: coffee
          method: delete
resources:
  Resources:
    CoffeeTable:
      Type: AWS::DynamoDB::Table
      Properties:
        TableName: CoffeeOrders-${self:provider.stage}
        AttributeDefinitions:
          - AttributeName: OrderId
            AttributeType: S
          - AttributeName: CustomerName
            AttributeType: S
        KeySchema:
          - AttributeName: OrderId
            KeyType: HASH
          - AttributeName: CustomerName
            KeyType: RANGE
        BillingMode: PAY_PER_REQUEST

The serverless.yml configuration defines how Alyx's Coffee Shop API will run in a serverless environment on AWS. The provider section specifies that the application will use AWS as the cloud provider, with Node.js as the runtime environment.

The region is set to us-east-1 and the stage variable allows for dynamic deployment across different environments, like dev and prod. This means that the same code can deploy to different environments, with resources being named accordingly to avoid conflicts.

In the iam section, permissions are granted to Lambda functions to interact with the DynamoDB table. The ${self:provider.stage} syntax dynamically names the DynamoDB table, so that each environment has its own separate resources, like CoffeeOrders-dev for the development environment and CoffeeOrders-prod for production. This dynamic naming helps manage multiple environments without manually configuring separate tables for each one.

The functions section defines the four core Lambda functions, createCoffee, getCoffee, updateCoffee and deleteCoffee. These handle the CRUD operations for the Coffee Shop API.

Each function is connected to a specific HTTP method in the API Gateway, such as POST, GET, PUT and DELETE. These functions interact with the DynamoDB table that’s dynamically named based on the current stage.

The last resources section defines the DynamoDB table itself. It sets up the table with the attributes OrderId and CustomerName, which are used as the primary key. The table is configured to use a pay-per-request billing mode, making it cost-effective for Alyx's growing business.

By automating the deployment of these resources using the Serverless Framework, Alyx can easily manage her infrastructure, freeing her from the burden of manually provisioning and scaling resources.

Step 3: Develop the Lambda Functions for CRUD Operations

In this step, we implement the core logic of Alyx’s Coffee Shop API by creating Lambda functions with JavaScript that perform the essential CRUD operations createCoffee, getCoffee, updateCoffee and deleteCoffee.

These functions utilize the AWS SDK to interact with AWS services, particularly DynamoDB. Each function will be responsible for handling specific API requests such as creating an order, retrieving orders, updating order statuses, and deleting orders.

Create Coffee Lambda function

This function creates an order:

const AWS = require('aws-sdk');
const dynamoDb = new AWS.DynamoDB.DocumentClient();
const { v4: uuidv4 } = require('uuid');

module.exports.handler = async (event) => {
  const requestBody = JSON.parse(event.body);
  const customerName = requestBody.customer_name;
  const coffeeBlend = requestBody.coffee_blend;
  const orderId = uuidv4();

  const params = {
    TableName: process.env.COFFEE_ORDERS_TABLE,
    Item: {
      OrderId: orderId,
      CustomerName: customerName,
      CoffeeBlend: coffeeBlend,
      OrderStatus: 'Pending'
    }
  };

  try {
    await dynamoDb.put(params).promise();
    return {
      statusCode: 200,
      body: JSON.stringify({ message: 'Order created successfully!', OrderId: orderId })
    };
  } catch (error) {
    return {
      statusCode: 500,
      body: JSON.stringify({ error: `Could not create order: ${error.message}` })
    };
  }
};

This Lambda function handles the creation of a new coffee order in the DynamoDB table. First we import the AWS SDK and initialize a DynamoDB.DocumentClient to interact with DynamoDB. The uuid library is also imported to generate unique order IDs.

Inside the handler function, we parse the incoming request body to extract customer information, such as the customer's name and preferred coffee blend. A unique orderId is generated using uuidv4() and this data is prepared for insertion into DynamoDB.

The params object defines the table where the data will be stored, with TableName dynamically set to the value of the environment variable COFFEE_ORDERS_TABLE. The new order includes fields such as OrderId, CustomerName, CoffeeBlend, and an initial status of Pending.

In the try block, the code attempts to add the order to the DynamoDB table using the put() method. If successful, the function returns a status code of 200 with a success message and the OrderId. If there’s an error, the code catches it and returns a 500 status code along with an error message.

Get Coffee Lambda function

This function retrieves all coffee items:

const AWS = require('aws-sdk');
const dynamoDb = new AWS.DynamoDB.DocumentClient();

module.exports.handler = async () => {
  const params = {
    TableName: process.env.COFFEE_ORDERS_TABLE
  };

  try {
    const result = await dynamoDb.scan(params).promise();
    return {
      statusCode: 200,
      body: JSON.stringify(result.Items)
    };
  } catch (error) {
    return {
      statusCode: 500,
      body: JSON.stringify({ error: `Could not retrieve orders: ${error.message}` })
    };
  }
};

This Lambda function is responsible for retrieving all coffee orders from a DynamoDB table and exemplifies a serverless approach to retrieving data from DynamoDB in a scalable manner.

We again use the AWS SDK to initialize a DynamoDB.DocumentClient instance to interact with DynamoDB. The handler function constructs the params object, specifying the TableName, which is dynamically set using the COFFEE_ORDERS_TABLE environment variable.

The scan() method retrieves all items from the table. Again, if the operation is successful, the function returns a status code of 200 along with the retrieved items in JSON format. In case of an error, a 500 status code and an error message are returned.

Update Coffee Lambda function

This function updates a coffee item by its ID:

const AWS = require('aws-sdk');
const dynamoDb = new AWS.DynamoDB.DocumentClient();

module.exports.handler = async (event) => {
  const requestBody = JSON.parse(event.body);
  const { order_id, new_status, customer_name } = requestBody;

  const params = {
    TableName: process.env.COFFEE_ORDERS_TABLE,
    Key: {
      OrderId: order_id,
      CustomerName: customer_name
    },
    UpdateExpression: 'SET OrderStatus = :status',
    ExpressionAttributeValues: {
      ':status': new_status
    }
  };

  try {
    await dynamoDb.update(params).promise();
    return {
      statusCode: 200,
      body: JSON.stringify({ message: 'Order status updated successfully!', OrderId: order_id })
    };
  } catch (error) {
    return {
      statusCode: 500,
      body: JSON.stringify({ error: `Could not update order: ${error.message}` })
    };
  }
};

This Lambda function handles updating the status of a specific coffee order in the DynamoDB table.

The handler function extracts the order_id, new_status, and customer_name from the request body. It then constructs the params object to specify the table name and the primary key for the order (using OrderId and CustomerName). The UpdateExpression sets the new status of the order.

In the try block, the code attempts to update the order in DynamoDB using the update() method. Once again, of course if successful, the function returns a status code of 200 with a success message. If an error occurs, it catches the error and returns a 500 status code along with an error message.

Delete Coffee Lambda function

This function deletes a coffee item by its ID:

const AWS = require('aws-sdk');
const dynamoDb = new AWS.DynamoDB.DocumentClient();

module.exports.handler = async (event) => {
  const requestBody = JSON.parse(event.body);
  const { order_id, customer_name } = requestBody;

  const params = {
    TableName: process.env.COFFEE_ORDERS_TABLE,
    Key: {
      OrderId: order_id,
      CustomerName: customer_name
    }
  };

  try {
    await dynamoDb.delete(params).promise();
    return {
      statusCode: 200,
      body: JSON.stringify({ message: 'Order deleted successfully!', OrderId: order_id })
    };
  } catch (error) {
    return {
      statusCode: 500,
      body: JSON.stringify({ error: `Could not delete order: ${error.message}` })
    };
  }
};

The Lambda function deletes a specific coffee order from the DynamoDB table. In the handler function, the code parses the request body to extract the order_id and customer_name. These values are used as the primary key to identify the item to be deleted from the table. The params object specifies the table name and key for the item to be deleted.

In the try block, the code attempts to delete the order from DynamoDB using the delete() method. If successful, again it returns a 200 status code with a success message, indicating that the order was deleted. If an error occurs, the code catches it and returns a 500 status code along with an error message.

Now that we’ve explained each Lambda function, let’s set up a multi-stage CI/CD pipeline.

Step 4: Set Up CI/CD Pipeline Multi-stage Deployments for Dev and Prod Environments

To set up AWS secrets in your GitHub repository, first navigate to the repository’s settings. Select Settings on the top right, then go to the bottom left and select Secrets and variables.

Next, click on Actions as seen in the image below:

From there, select New repository secret to create secrets.

Three secrets are needed to create for your pipeline, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and SERVERLESS_ACCESS_KEY.

Use your AWS account access key credentials for the first two variables and then the serverless access key previously saved to create the SERVERLESS_ACCESS_KEY. These secrets will securely authenticate your CI/CD pipeline as seen in the image below.

Make sure that your main branch is named “main,” as this will serve as the production branch. Next, create a new branch called “dev” for development work.

You can also create feature-specific branches, such as “dev/feature,” for more granular development. GitHub Actions will use these branches to deploy changes automatically, with dev representing the development environment and main representing production.

This branching strategy allows you to manage the CI/CD pipeline efficiently, deploying new code changes whenever there's a merge into either the dev or prod environments.

How to Use GitHub Actions to Deploy the YAML File

To automate the deployment process for the Coffee Shop API, you'll utilize GitHub Actions, which integrates with your GitHub repository.

This deployment pipeline is triggered whenever code is pushed to the main or dev branches. By configuring environment-specific deployments, you'll ensure that updates to the dev branch deploy to the development environment, while changes to the main branch trigger production deployments.

Now, let’s review the code:

name: deploy-coffee-shop-api

on:
  push:
    branches:
      - main
      - dev

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Setup Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '20.x'

    - name: Install dependencies
      run: |
        cd coffee-shop-api
        npm install

    - name: Install Serverless Framework
      run: npm install -g serverless

    - name: Deploy to AWS (Dev)
      if: github.ref == 'refs/heads/dev'
      run: |
        cd coffee-shop-api
        npx serverless deploy --stage dev
      env:
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        SERVERLESS_ACCESS_KEY: ${{secrets.SERVERLESS_ACCESS_KEY}}

    - name: Deploy to AWS (Prod)
      if: github.ref == 'refs/heads/main'
      run: |
        cd coffee-shop-api
        npx serverless deploy --stage prod
      env:
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        SERVERLESS_ACCESS_KEY: ${{secrets.SERVERLESS_ACCESS_KEY}}

The GitHub Actions YAML configuration is what automates the deployment process of the Coffee Shop API to AWS using the Serverless Framework. The workflow triggers whenever changes are pushed to the main or dev branches.

It begins by checking out the repository’s code, then setting up Node.js with version 20.x to match the runtime used by the Lambda functions. After that, it installs the project dependencies by navigating to the coffee-shop-api directory and running npm install.

The workflow also installs the Serverless Framework globally, allowing the serverless CLI to be used for deployments. Depending on which branch is updated, the workflow conditionally deploys to the appropriate environment.

If the changes are pushed to the dev branch, it deploys to the dev stage. If they are pushed to the main branch, it deploys to the prod stage. The deployment commands, npx serverless deploy --stage dev or npx serverless deploy --stage prod are executed within the coffee-shop-api directory.

For a secure deployment, the workflow accesses AWS credentials and the Serverless access key via environment variables stored in GitHub Secrets. This allows the CI/CD pipeline to authenticate with AWS and the Serverless Framework without exposing sensitive information in the repository.

Now, we can proceed to test out the pipeline.

Step 5: Test the Dev and Prod Pipelines

First, you'll need to verify that the main (prod) branch is called “main”. Then create a dev branch called “dev”. Once you make any valid changes to the dev branch, commit them to trigger the GitHub Actions pipeline. This will automatically deploy the updated resources to the development environment. After verifying everything in dev, you can then merge the dev branch into the main branch.

Merging changes into the main branch also automatically triggers the deployment pipeline for the production environment. This way, all necessary updates are applied and production resources are deployed seamlessly.

You can monitor the deployment process and review detailed logs of each GitHub Actions run by navigating to the Actions tab in your GitHub repository.

The logs provide visibility into each step of the pipeline, helping you verify that everything is working as expected.

You can select any build run to review detailed logs for both the development and production environment deployments so you can track the progress and ensure that everything is running smoothly.

Navigate to the specific build run in GitHub Actions, as demonstrated in the image below. There, you can view the execution details and outcomes for either the development or production pipelines.

Make sure to thoroughly test both the development and production environments to confirm successful pipeline executing.

Step 6: Test and Validate Prod and Dev APIs using Postman

Now that the APIs and resources are deployed and configured, we need to locate the unique API endpoints (URLs) generated by AWS to begin making requests to test functionality.

These URLs can test the API functionality by simply pasting them into a web browser. The API URLs are found in the output results of your CI/CD build.

To retrieve them, navigate to the GitHub Actions logs, select the most recent environment’s successful build, and click deploy to check the deployment details for the generated API endpoints.

Click on the Deploy to AWS stage for the selected environment (Prod or Dev) in your GitHub Actions logs. Once there, you’ll find the generated API URL.

Copy and save this URL, as it will be needed when testing your API’s functionality. This URL is your gateway to verifying that the deployed API works as expected.

Now copy one of the generated API URLs and paste it into your browser. You will see an empty array or list displayed in the response. This actually confirms that the API is functioning correctly and that you are successfully retrieving data from the DynamoDB table.

Even though the list is empty, it indicates that the API can connect to the database and return information.

To verify that your API works across both environments, repeat the steps for the other API environment (Prod and Dev).

For more comprehensive testing, we’ll use Postman to test all the API methods, Create, Read, Update and Delete, and perform these tests for both the development and production environments.

To test the GET method, use Postman to send a GET request to the API’s endpoint using the URL. You will receive the same response, an empty list of coffee orders as seen in the bottom of the image below. This confirms the API’s ability to retrieve data successfully, as shown in the image below.

To actually create an order, let’s test the POST method. Use Postman again to make a POST request to the API endpoint, providing the customer’s name and coffee blend in the request body, as show below :

{
  "customer_name": "REXTECH",
  "coffee_blend": "Black"
}

The response will be a success message with a unique OrderId of the order placed.

Verify that the new order was saved in the DynamoDB table by reviewing the items in the environments specific table :

To test the PUT method, make a PUT request to the API endpoint by providing the previous order ID and a new order status in the request body as shown below :

{                                                 
  "order_id": "42a81c27-1421-4025-9bef-72b14e723c34",
  "new_status": "Ready",                                             
  "customer_name": "REXTECH"                                             
}

The response will be a successful order update message with the OrderId of the order placed.

You can also verify that the order status was updated from the DynamoDB table item.

To test the DELETE method, using Postman, make a DELETE request providing the previous order ID and the customer name in the request body as shown below:

{                                                 
  "order_id": "42a81c27-1421-4025-9bef-72b14e723c34",
  "customer_name": "REXTECH"
}

The response will be a successful order deleted message with the order ID of the order placed.

Again, you can verify that the order has been deleted in the DynamoDB table.

Conclusion

That’s it – congratulations! You’ve successfully completed all the steps. We’ve built a serverless REST API that supports CRUD (Create, Read, Update, Delete) functionality with API Gateway, Lambda, DynamoDB, Serverless Framework and Node.js, automating deployment of approved code changes with Github Actions.

If you’ve gotten this far, thanks for reading! I hope it was worthwhile to you.

Ifeanyi Otuonye is a 6X AWS Certified Cloud Engineer skilled in DevOps, Technical Writing and instructional expertise as a Technical Instructor. He is motivated by his eagerness to learn and develop and thrives in collaborative environments. Before transitioning to the Cloud, he spend six years as a Professional Track and Field athlete.

In the early 2022, he strategically embarked on an mission to be a Cloud/DevOps Engineer through self study and joining a 6 month accelerated Cloud program.

In May 2023, he accomplished that goal and landed his first Cloud Engineering role and has now set another personal mission to empower other individuals on their journey to the Cloud.

In the realm of serverless computing, AWS Lambda stands out as a leading platform for running serverless functions in a scalable and cost-effective manner.

Table of Contents

• What is Serverless Framework?
• Purpose and Scope of the Guide
• Prerequisites
• How to Configure the AWS CLI
• How to Create the IAM Role
• How to Create a Serverless Project
• How to Write the Python Function
• How to Define Serverless Configuration
• How to Deploy the Python Function
• How to Test the API
• Monitoring and Logging
• Conclusion

What is Serverless Framework?

Serverless Framework is a powerful tool that simplifies the deployment and management of serverless applications across various cloud providers, including Amazon Web Services (AWS). This guide aims to walk you through the process of using the Serverless Framework to deploy a simple Python function to AWS Lambda, expose it via API Gateway, and monitor it using AWS CloudWatch.

Purpose and Scope of the Guide

The purpose of this guide is to provide you with a step-by-step tutorial on deploying a serverless Python function on AWS using the Serverless Framework. Whether you're new to serverless computing or looking to expand your skills, this tutorial is designed to help you with the following:

• How to set up the necessary prerequisites, including AWS account configuration.
• How to create a new serverless project using the Serverless Framework.
• How to write a Python function that will be deployed to AWS Lambda.
• How to define the serverless configuration in a serverless.yml file.
• How to deploy the Python function and API Gateway.
• How to test the deployed API using various tools like cURL or Postman.
• How to set up monitoring and logging with AWS CloudWatch.

By the end of this article, you'll have a clear understanding of how to leverage the Serverless Framework to deploy and manage serverless applications on AWS.

You'll also gain practical experience in deploying serverless functions and exposing them through an API endpoint, paving the way for building and scaling serverless applications in your projects.

Now, let's dive into the prerequisites needed to get started with this tutorial.

Prerequisites

To follow along with this tutorial, you'll need the following:

• An AWS account.
• The AWS CLI (Command Line Interface).
• The Serverless Framework.

How to Configure the AWS CLI

You'll need to set the AWS credentials for the AWS CLI if you have not done that already. You'll be using it along with the Serverless Framework to deploy the resources on AWS.

You can create the AWS credentials file by entering the following command in the terminal:

 cat <<EOF > ~/.aws/credentials
    [default]
    aws_access_key_id = <REPLACE_WITH_YOUR_SECRET_KEY>
    aws_secret_access_key = <REPLACE_WITH_YOUR_ACCESS_KEY> 
  EOF

  cat <<EOF > ~/.aws/config
    [default]
    region = eu-west-1
    output = json
  EOF

How to Create the IAM Role

The IAM role is also used by the Serverless Framework to deploy the resources on AWS. Enter the following command to create the role:

 aws iam create-role --role-name serverlessLabs --assume-role-policy-document '{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}'

This policy allows the role to be used by the AWS Lambda service.

Enter the following command to attach the AWSLambdaBasicExecutionRole policy to the role:

aws iam attach-role-policy --role-name serverlessLabs --policy-arn arn:aws:iam::aws:policy/AWSLambda_FullAccess

To verify that the role has been created successfully, you can run the following command to get information about the IAM role:

aws iam get-role --role-name serverlessLabs

Here's what the information should look like:

How to Create a Serverless Project

This project is a simple python function that is deployed to AWS Lambda, API Gateway, and CloudWatch using the Serverless Framework.

The function is triggered by an HTTP GET request and returns a simple string. The function is deployed to the eu-west-1 region.

First, install Serverless Framework using npm:

npm install -g serverless

Next, create a new Serverless Framework project using the serverless command and then follow the prompt:

serverless

Then choose AWS Python Starter from the template list. Give it any name of your choice – I used serverless-lab.

After the command runs successfully, you will see the two main components created: serverless.yaml, and handler.py.

How to Write the Python Function

To keep things organized, let's create a folder named functions, and create a file named __init__.py inside it. You can do that using this command:

mkdir functions  touch functions/__init__.py

Create your first function by creating a file named first_function.py inside the functions folder:

touch functions/first_function.py

Then open the first_function.py file, and paste the following Python code to define the function you'll deploy:

def first_function(event, context):
  print("The first function has been invoked!!")
  return {
    'statusCode': 200,
    'body': "Hello, World!.\n This is the first function."
  }

This code above is a simple Python function that returns a JSON object with status code and body values. As you can see, we inserted the two parameters — event and context — required from the functions as a Serverless Framework convention.

Next, open the handler.py file and delete its content and paste the following Python code to define the handler that will be invoked when the function is triggered:

from functions.first_function import first_function

The code above exposes the function you created in the first_function.py file. We imported the function, and exposed it to the framework.

How to Define Serverless Configuration

To start with the configuration, open the serverless.yaml file and delete all of its content and paste the following YAML code to define the microservice you will deploy:

service: serverless-lab

provider:
  name: aws
  runtime: python3.7
  lambdaHashingVersion: 20201221
  region: eu-west-1
  timeout: 10 # You set a timeout of 10 seconds for the functions
  role: arn:aws:iam::155318317806:role/serverlessLabs # Enter your Arn role here
  memorySize: 512

functions:
  first_function:
    handler: handler.first_function
    events:
    - http:
        path: first
        method: get

Let's break down each section line by line:

service: serverless-lab

**service** specifies the name of your Serverless service or project. In this case, it's named "serverless-lab," which will be used as the service name when deploying to AWS.

provider:
  name: aws
  runtime: python3.7
  lambdaHashingVersion: 20201221
  region: eu-west-1 # enter your region
  profile: personalCaesarAcc
  timeout: 10 # You set a timeout of 10 seconds for the functions
  role: arn:aws:iam::155318317806:role/serverlessLabs # Enter your Arn role here
  memorySize: 512

**provider** defines the AWS provider for your service. It specifies various configuration settings for AWS Lambda functions and other AWS resources.

• name: aws specifies that you are using AWS as your cloud provider.
• runtime: python3.7 sets the runtime for AWS Lambda functions to Python 3.7.
• lambdaHashingVersion: 20201221 specifies the Lambda function hashing version. This is an internal AWS setting.
• region: eu-west-1 specifies the AWS region where your service will be deployed. You can replace "eu-west-1" with your desired AWS region.
• timeout: 10 sets a timeout of 10 seconds for AWS Lambda functions. This means that each function should complete its execution within 10 seconds.
• role: arn:aws:iam::155318317806:role/serverlessLabs specifies the AWS IAM role ARN that your Lambda functions will assume. This role defines the permissions your functions have within AWS services. You can replace this with the ARN of your desired IAM role.

functions:
  first_function:
    handler: handler.first_function
    events:
    - http:
        path: first
        method: get

**functions** defines the AWS Lambda functions in your service.

• first_function denotes the name of your AWS Lambda function.
• handler: handler.first_function specifies the entry point for this function, which is handler.first_function in the handler module. This is typically in the <module_name>.<function_name> format.
• events specifies the events that triggers the function.
• - http indicates that the function is triggered by an HTTP event (API Gateway).
• path: first specifies the API endpoint path (/first) that triggers the function.
• method: get specifies that this function is triggered when an HTTP GET request is made to the specified path.

How to Deploy the Python Function

You can use the command below to deploy the microservice on AWS:

serverless deploy

After a while, the deployment will be completed and you can see information like the endpoint, hosted on API Gateway, to trigger the function you just deployed.

The framework deployed the function on AWS Lambda and, because you attached an HTTP trigger to it. It has deployed an API on API Gateway to let the function be reachable.

How to Test the API

From the deployment, you have a single function named first_function, and a single HTTP GET endpoint.

Using the GET endpoint (the endpoint generated in the terminal after deploying the function) in your browser, you can call the function:

The image above shows the functionality created in the deployed function running in the browser.

Monitoring and Logging

The log group is automatically saved on AWS CloudWatch because there is a print statement defined in the function. Enter the following command to access the function's logs:

serverless logs -f first_function

AWS CloudWatch is the native AWS logging service that lets you monitor and access logs from your applications. You can find log groups, and you can also apply filter expressions on logs to retrieve those you need.

You can delete the microservice and resources you just deployed using the serverless remove command.

Check out my GitHub repository to see the full code

Conclusion

In this comprehensive guide, we've explored the powerful world of serverless computing and demonstrated how to harness its capabilities using the Serverless Framework and Amazon Web Services (AWS).

You've embarked on a journey from setting up your development environment to deploying a simple Python function as an AWS Lambda-backed API, all while gaining insights into monitoring and logging with AWS CloudWatch.

This guide serves as a starting point for your serverless journey. As you become more proficient with the Serverless Framework and AWS, you'll be able to build and deploy sophisticated serverless applications that scale dynamically and meet the demands of modern, cloud-native architectures.

As always, I hope you enjoyed the article and learned something new. If you want, you can also follow me on LinkedIn or Twitter.

Serverless Development has been around since the release of AWS Lambda in 2014, but in the last few years things have exploded.

Startups and smart tech companies have started taking advantage of the scalability, reliability, and power of serverless to rapidly grow – and now they need more serverless developers than ever.

Being a "Serverless Developer" means you build solutions with managed services from the likes of AWS, Google Cloud (GCP), or Azure. You build solutions by piecing together different services and running all of your business logic in AWS Lambda or CGP Cloud Functions instead of on a server.

With your cloud platform dealing with almost all of the operations (security, redundancy, scalability, and networking), you're left to focus on building the best solutions you can. This means features can be built quicker and companies don't need to hire operations specialists.

This article will cover the 5 steps to learning how to become a serverless developer so you can build some kick-butt products.

In Summary

1. Have solid JavaScript or Python skills. You don't have to be a wizard but being comfortable write an Express or Flask server will make the rest much easier.

2. Pick your framework – choose either The Serverless Framework or AWS CDK.

3. Follow a tutorial to start learning to build with your framework. Start with building an API with API Gateway and Lambda.

4. Learn more about the services you're using. What are the benefits, limitations, good use cases and bad ones?

5. Build what you've learnt in the tutorials into your own project.

Now you've learnt to build an API, add some more services, repeating steps 3-5 each time. A good order could be:

• DynamoDB – getting and writing data

• S3 – reading and writing files

• DynamoDB – with secondary indexes and queries

• Cognito – Authorisation for your API

• AppSync – GraphQL API

1. Solid JavaScript or Python Skills

Before trying to build serverless systems, you really need to have a good grasp on the fundamentals of one of the common programming languages. You don't need to be a wizard, but being comfortable using your chosen language is key.

The reason you need to be comfortable writing good code is that it has a massive effect on the software you build. Serverless is like building blocks and the Lambda code is like the glue. In that code, you write the logic for connecting each part.

You could have the perfect architecture but if your Lambda code is buggy, your solution will be, too.

I recommend either JavaScript (TypeScript) or Python. The reason I recommend these two languages is that most of the companies that will be using Serverless Architecture will be using one of these two languages. Luckily they're also the two languages taught here on FreeCodeCamp 🎉 .

Being the most widely used they also have more tutorials and a bigger community to help when you get stuck.

Another reason that I recommend these languages is that you can write the framework code with the same language you write the Lambda code with. You'll be constantly jumping between lambda code and frameworks config. Not having to switch between languages will save a LOT of you brain juice 🧠

2. Pick your Framework

With a solid grasp of your language, you need a tool to help you create the serverless components in AWS.

There are LOT out there, but I would say you should pick either the Serverless Framework or AWS CDK. I have a bias towards the Serverless Framework as I have a Youtube channel with over 50 videos on building with it. If you're a Python developer then maybe the AWS CDK might be better suited for you.

Why use a framework?

When building a solution it is possible to do it all in the AWS Console. That's how I started my AWS journey.

The issue is that it is not controllable, manageable or scalable. If you want to copy this setup to another account (separate dev and prod accounts) you have to remember all the steps you've done. Working with multiple team members can get messy.

That is why it's helpful to use a framework to allow us to write Infrastructure-as-Code (IaC). This allows us to use Git for version control. This makes working as a team much easier, enables multi-environment deployments, even continuous integration and deployment. All things that are required when running production workloads

The Serverless Framework

• Proven in large, production workloads

• Easy to get started

• Large community

• Lots of tutorials

• Lots of plugins to make many jobs easier

• Not as easy when doing things that aren't serverless

• If you're using Python, you'll have to configure it with YAML

AWS CDK

• From AWS and is actively developed by them

• Good support for almost anything in AWS

• Some cool ways to create re-usable constructs

• Growing community and pool of tutorials

• Can define the config using Python

• Not the same 'Plugins' ecosystem as the Serverless Framework

Other Frameworks

Some of you may say "What about all of the other frameworks?" and I'll address those.

AWS SAM & AWS Amplify

These frameworks are designed to be very easy to do simple things. If you're reading this then you could probably use these to create an API and website quickly and easily.

This is great if that is all you want to do. But if you want more control over how they are deployed or want to deploy more complex systems then you're going to struggle.

Terraform & Ansible

These frameworks have been around for a long time and are used in enterprise as their Infrastructure as Code (IaC) tool.

The reasons I wouldn't learn these as my first framework are:

1. You have to learn a new language. Terraform uses HCL (Hashcorp Language) and Ansible uses YAML. Leaning a new language whilst trying to learn about Serverless architecture isn't ideal. Also switching into that language when you need to create infrastructure is brain zapping.

2. They are opinionated and strict. Getting a small thing not configured perfectly will just not work, often with a hard to understand error.

3. They're not as flexible or powerful as CDK or Serverless Framework.

Webiny & Serverless Cloud

These are very new frameworks that are trying to make IaC as simple but as powerful as possible.

The reason that I would avoid these for now is that they're just too new. This has two drawbacks:

1. The community isn't as big. This means fewer tutorials and fewer people to ask if you get stuck

2. Things change quickly. Best practices and common structure, but sometimes APIs, methods and parameters too. When learning a framework you don't want to have to deal with this stuff.

If there is a feature you absolutely need to use and you have someone who is very experienced with that specific framework, then it could work. I would still recommend one of the main two.

3. Follow a tutorial

With your framework chosen, you can now start building things with it.

The first thing you should build is an API using just Lambda and API Gateway. This is very simple but will get you practice with the core fundamentals of the framework. Understanding the fundamentals will make learning more advanced things much easier.

Why Follow a Tutorial

When learning a new service, it may be tempting to try and learn it by adding it straight into an existing project. I would recommend always trying to follow a tutorial the first time you work with any new service or tool.

When you follow a tutorial it should work without any issues. This means you can focus on learning about the service and how it fits in with everything else.

Adding it into your own project means if something doesn't work you've got to debug it on your own. You might not know whether you've used the service wrong or if there is a bug connecting it to your existing system.

4. Learn more about the services you're using

Now that you've used the new service, it's a good idea to learn a bit more about it. The key things I would want to know about a service I use are:

1. What are its strengths, weaknesses, and limitations?

2. What are some ideal use cases for using the service?

3. What are some use cases where you should avoid using this service?

Knowing these three things, you will be much better able to decide whether a service will be a good fit for the solution you are currently building.

You can learn from a range of places: tutorials, articles, and even the AWS Docs.

For example, AWS Lambda is great for most APIs, but can't run for more than 15 minutes. If I need to build an API that does some batch processing that takes 10-20 minutes then it would time out half of the time. Therefore I need to find another solution.

Again you don't need to understand every little detail about every service, just enough to know when it is a good idea to use and when not to.

5. Build your own projects

Now you know how to build with the new service (from the tutorials) and have a good understanding of when to use the service.

From here it is time to use these services in your own projects.

I would recommend starting with a personal project that you use just for practicing using new services in. That way you don't have to worry about breaking things and you can focus on how the service is working.

You can now start using it in production apps and this is where you'll learn a lot about the details of a service. You learn how to make it meet the business requirements and how it works with other services. If you can do this as part of your job, even better. Else have a deployed app that you treat with the same care.

Repeat steps 3-5

Congratulations! You've learnt how to build an API using a framework.

That isn't the end, as there's always more to learn and a way to become a better serverless developer. Pick a new topic, service, or design pattern and repeat steps 3-5.

If you've just made your first serverless API, then here are the next topics and services I would learn to continue your journey.

• DynamoDB – creating a simple table, getting and writing data

• S3 – creating an S3 bucket, reading and writing files

• DynamoDB – with secondary indexes and queries

• Cognito – Authorisation for your API

• AppSync – GraphQL API

After that, focus on creating features for your solutions and use that to guide what to learn next.

If you're a JavaScript developer wanting to use the Serverless Framework, then a great place to start is my Youtube channel where we create tutorials on becoming the best Serverless Developer that you can be.

This article will teach you how to build and deploy everything you need to be able to build a back-end for your application. We'll be using AWS to host all of this and deploying it all using the Serverless Framework.

By the end of this article you'll know how to:

• Set up your AWS account to work with the Serverless Framework
• Set up a Serverless Project and deploy a Lambda
• Create private cloud storage with S3 bucket and upload files from your computer
• Deploy an API using API Gateway and AWS Lambda
• Create a serverless database table with AWS DynamoDB
• Create an API to get data from your DynamoDB table
• Create an API to add data to your DynamoDB table
• Create APIs to store files and get files from your S3 bucket
• Secure all of your API endpoints with API keys

Being able to do all these things gives you the ability to create all the functionality needed from most application back ends.

Serverless Setup with AWS

The Serverless Framework is a tool that we can use as developers to configure and deploy services from our computers. There's a bit of setup to allow all of this to work together and this section will show you how to do that.

Embedded content

To allow Serverless to do work on your account, you need to set up a user for it. To do this, navigate into AWS and search for "IAM" (Identity and Access Management).

Once on the IAM Page, click on Users in the list on the left hand side. This will open the list of users on your account. From here we'll be clicking Add user.

We need to create a user which has Programmatic access and I've called my user ServerlessAccount, but the name doesn't matter too much.

Next, we need to give the user some permissions. When on the permissions screen, select Attach existing policies directly and then select AdministratorAccess. This will give the Serverless Framework permission to create all the resources it needs to.

We don't need to add any tags, so we can move straight onto Review.

On the review window, you'll see the user has been given an Access key ID and a Secret access key. We'll be needing those in the next part so keep this page open.

Serverless Install and Configuration

Now that we've created our user, we need to install the Serverless Framework on our machine.

Open up a terminal and run this command to install Serverless globally on your computer. If you haven't got NodeJS installed check out this page.

npm install -g serverless

Now that we've got Serverless installed, we need to set up the credentials for Serverless to use. Run this command, putting your access key ID and Secret access key in the correct places:

serverless config credentials --provider aws --key ${Your access key ID} --secret ${Your secret access key} --profile serverlessUser

Once this has been run, you're all set up with Serverless.

Deploying Your First AWS Lambda

With out serverlessUser set up, we want to deploy something using the Serverless Framework. We can use Serverless templates to setup a basic project that we can deploy. This will be the base for the whole of this Serverless project.

Embedded content

In your terminal we can create a Serverless project from a template. This command will create a NodeJS Serverless project in the myServerlessProject folder:

serverless create --template aws-nodejs --path myServerlessProject

If you now open the folder up in your code editor we can look at what we've created.

We've got two file worth talking about: handler.js and serverless.yml

handler.js

This file is a function that will be uploaded as a Lambda function to your AWS account. Lambda functions are great and we'll use a lot more of them later on in the series.

serverless.yml

This is a very important file for us. This is where all the configuration for our deployment goes. It tells Serverless what runtime to use, which account to deploy to, and what to deploy.

We need to make a change to this file so that our deployment works properly. In the provider object we need to add a new line of profile: serverlessUser. This tells Serverless to use the AWS credentials we created in the last section.

We can scroll down to functions and see that we have one function which is called hello and points to the function within the handler.js file. This means we will be deploying this Lambda function as part of this project.

We'll learn a lot more about this serverless.yml file later on in this article.

Deploying Our Project

Now that we've looked at the files it's time to do our first deployment. Open up a terminal and navigate to our project folder. Deploying is as simple as typing:

serverless deploy

This takes a while, but when it's done we can check that everything has deployed successfully.

Open up your browser and navigate to your AWS account. Search for Lambda and you'll see a list of all your Lambda functions. (If you don't see any then check that your region is set to N. Virginia). You should see the myserverlessproject-dev-hello Lambda which contains the exact code that is in the handler.js file in your project folder.

Deploying an S3 Bucket and Uploading Files

In this section we're going to learn how we can deploy an Amazon S3 bucket and then sync up files from our computer. This is how we can start using S3 as cloud storage for our files.

Embedded content

Open up the serverless.yml file and remove all the commented out lines. Scroll to the bottom of the file and add the following code to include our S3 resources:

resources:
    Resources:
        DemoBucketUpload:
            Type: AWS::S3::Bucket
            Properties:
                BucketName: EnterAUniqueBucketNameHere

Change the name of the bucket and we're ready to deploy again. Open up your terminal again and run serverless deploy. You may get an error saying that the bucket name is not unique, in which case you'll need to change the bucket name, save the file and rerun the command.

If it is successful we can then go and see our new S3 bucket in our AWS Console through our browser. Search for S3 and then you should see your newly created bucket.

Syncing up your files

Having a bucket is great, but now we need to put files in the bucket. We're going to be using a Serverless plugin called S3 Sync to do this for us. To add this plugin to our project we need to define the plugins. After your provider object, add this code:

plugins:
    - serverless-s3-sync

This plugin also needs some custom configuration, so we add another field to our serverless.yml file, changing out the bucket name for yours:

custom:
    s3Sync:
        - bucketName: YourUniqueBucketName
          localDir: UploadData

This section of code is telling the S3 Sync plugin to upload the contents of the UploadData folder to our bucket. We don't currently have that folder so we need to create it and add some files. You can add a text file, an image, or whatever you want to be uploaded, just make sure there is at least 1 file in the folder.

The last thing we need to do is to install the plugin. Luckily, all Serverless plugins are also npm packages, so we can install it by running npm install --save-dev serverless-s3-sync in our terminal.

As we've done before, we can now run serverless deploy and wait for the deployment to complete. Once it is complete we can go back into our browser and into our bucket and we should see all the files that we put in the UploadData folder in our project.

Creating an API with Lambda and API Gateway

In this section we'll learn to do one of the most useful things with Serverless: create an API. Creating an API allows you to do so many things, from getting data from databases, S3 storage, hitting other APIs, and much more!

Embedded content

To create the API we first need to create a new Lambda function to handle the request. We're going to make a few Lambdas, so we're going to create a lambdas folder in our project with two subfolders, common and endpoints.

Inside the endpoints folder we can add a new file called getUser.js. This API is going to allow someone to make a request and get back data based on the ID of a user. This is the code for the API:

const Responses = require('../common/API_Responses');

exports.handler = async event => {
    console.log('event', event);

    if (!event.pathParameters || !event.pathParameters.ID) {
        // failed without an ID
        return Responses._400({ message: 'missing the ID from the path' });
    }

    let ID = event.pathParameters.ID;

    if (data[ID]) {
        // return the data
        return Responses._200(data[ID]);
    }

    //failed as ID not in the data
    return Responses._400({ message: 'no ID in data' });
};

const data = {
    1234: { name: 'Anna Jones', age: 25, job: 'journalist' },
    7893: { name: 'Chris Smith', age: 52, job: 'teacher' },
    5132: { name: 'Tom Hague', age: 23, job: 'plasterer' },
};

If the request doesn't contain an ID then we return a failed response. If there is data for that ID then we return that data. If there isn't data for that user ID then we also return a failure response.

As you may have noticed we are requiring in the Responses object from API_Responses. These responses are going to be common to every API that we make, so making this code importable is a smart move. Create a new file called API_Responses.js in the common folder and add this code:

const Responses = {
    _200(data = {}) {
        return {
            headers: {
                'Content-Type': 'application/json',
                'Access-Control-Allow-Methods': '*',
                'Access-Control-Allow-Origin': '*',
            },
            statusCode: 200,
            body: JSON.stringify(data),
        };
    },

    _400(data = {}) {
        return {
            headers: {
                'Content-Type': 'application/json',
                'Access-Control-Allow-Methods': '*',
                'Access-Control-Allow-Origin': '*',
            },
            statusCode: 400,
            body: JSON.stringify(data),
        };
    },
};

module.exports = Responses;

This set of functions are used to simplify the creation of the correct response needed when using a Lambda with API Gateway (which we'll do in a sec). The methods add headers, a status code, and stringify any data that needs to be returned.

Now that we have the code for our API, we need to set it up in our serverless.yml file. Scroll to the functions section of the serverless.yml file. In the last part of this guide we deployed the hello function, but we no longer need that. Delete the functions object and replace it with this:

functions:
    getUser:
        handler: lambdas/endpoints/getUser.handler
        events:
            - http:
                  path: get-user/{ID}
                  method: GET
                  cors: true

This code is creating a new Lambda function called getUser which is in the file of lambdas/getUser on the method of handler. We then define the events that can trigger this lambda function to run.

To make a Lambda into an API we can add a http event. This tells Serverless to add an API Gateway to this account and then we can define the API endpoint using path. In this case get-user/{ID} means the URL will be https://${something-provided-by-API-Gateway}/get-user/{ID}, where the ID is passed into the Lambda as a path parameter. We also set the method to GET and enable CORS so that we could access this endpoint from a front end application if we wanted.

We can now deploy again, and this time we can use the shorthand command sls deploy. This only saves a few characters, but helps avoid a lot of typos. When this is completed we'll get an output that also includes a list of endpoints. We can copy our endpoint and head over to a browser to test it out.

If we paste our API URL into our browser and then add an ID to the end of 5132 we should get back a response of { name: 'Tom Hague', age: 23, job: 'plasterer' }. If we enter a different ID such as 1234 we'll get different data, but entering an ID of 7890 or not entering an ID will return an error.

If we want to add more data to our API, we can simply add a new row to the data object in the getUser.js file. We can then run a special command which only deploys one function, sls deploy -f ${functionName}. So for us that is:

sls deploy -f getUser

If you now make a request using the ID of the new data, the API will return that new data instead of an error.

Creating a Database on AWS

DynamoDB is a fully hosted, non-relational database on AWS. This is the perfect solution for storing data that you need to access and update regularly. In this section we're going to learn how we can create a DynamoDB table with Serverless.

Embedded content

In our serverless.yml file we're going to add some configuration to the Resources section:

resources:
    Resources:
        DemoBucketUpload:
            Type: AWS::S3::Bucket
            Properties:
                BucketName: ${self:custom.bucketName}
        # New Code
        MyDynamoDbTable:
            Type: AWS::DynamoDB::Table
            Properties:
                TableName: ${self:custom.tableName}
                AttributeDefinitions:
                    - AttributeName: ID
                      AttributeType: S
                KeySchema:
                    - AttributeName: ID
                      KeyType: HASH
                BillingMode: PAY_PER_REQUEST

In this code we can see that we are creating a new DynamoDB table with a TableName of ${self:custom.tableName}, defining an attribute of ID and setting the billing mode to pay per request.

This is our first look at the use of variables in our serverless.yml file. We can use variables for a few reasons and they can make our jobs much easier. In this case, we're referencing the variable custom.tableName. We can then reference this variable from multiple locations without having to copy and paste the table name. To get this to work we also need to add tableName to the custom section. In our case we're going to add the line tableName: player-points to create a table to store the points a player has. This table name only needs to be unique to your account.

When defining a table you need to define at least one of the fields which will be your unique identifying field. Because DynamoDB is a non-relational database, you don't need to define the full schema. In our case we've defined the ID, stating that it has an attribute type of string and a key type of HASH.

The last part of the definition is the billing mode. There are two ways to pay for DynamoDB:

• pay per request
• provisioned resources.

Provisioned resources lets you define how much data you're going to be reading and writing to the table. The issues with this are that if you start using more your requests get throttled, and that you pay for the resource even if no one is using it.

Pay Per Request it's much simpler as you just pay per request. This means if you have no one using it then you pay nothing and if your have hundreds of people using it at once, all the requests work. For this added flexibility you pay slightly more for Pay Per Request, but in the long run it usually works out to be cheaper.

Once we've run sls deploy again we can open up our AWS console and search for DynamoDB. We should be able to see our new table and we can see that there is nothing in there.

To add data to the table, click Create item, give it a unique ID, click the plus button and append to a new field and select the type of string. We need to give it a field of name and a value of Jess. Add a number field of score set to 12. Click save and you now have data in your dynamo table.

Getting Data from your DynamoDB Table

Now that we have our Dynamo table created, we want to be able to get and add data to the table. We're going to start with getting data from the table with a get endpoint.

Embedded content

We're going to create a new file in our endpoints folder called getPlayerScore.js. This Lambda endpoint is going to handle the requests for a user and get that data from the Dynamo table.

const Responses = require('../common/API_Responses');
const Dynamo = require('../common/Dynamo');

const tableName = process.env.tableName;

exports.handler = async event => {
    console.log('event', event);

    if (!event.pathParameters || !event.pathParameters.ID) {
        // failed without an ID
        return Responses._400({ message: 'missing the ID from the path' });
    }

    let ID = event.pathParameters.ID;

    const user = await Dynamo.get(ID, tableName).catch(err => {
        console.log('error in Dynamo Get', err);
        return null;
    });

    if (!user) {
        return Responses._400({ message: 'Failed to get user by ID' });
    }

    return Responses._200({ user });
};

The code used here is very similar to the code inside the getUser.js file. We are checking that a path parameter of ID exists, getting the user data, and then returning the user. The main difference is how we are getting the user.

We have imported the Dynamo function object and are calling Dynamo.get. We're passing in the ID and the table name and then catching any errors. We now need to create that Dynamo function object in a new file called Dynamo.js in the common folder.

const AWS = require('aws-sdk');

const documentClient = new AWS.DynamoDB.DocumentClient();

const Dynamo = {
    async get(ID, TableName) {
        const params = {
            TableName,
            Key: {
                ID,
            },
        };

        const data = await documentClient.get(params).promise();

        if (!data || !data.Item) {
            throw Error(`There was an error fetching the data for ID of ${ID} from ${TableName}`);
        }
        console.log(data);

        return data.Item;
    },
};
module.exports = Dynamo;

Reading and writing to Dynamo requires a reasonable amount of code. We could write that code every time we want to use Dynamo but it is much cleaner to have functions to simplify the process for us.

The file first imports AWS and then creates an instance of the DynamoDB Document Client. The document client is the easiest way for us to work with Dynamo from our Lambdas. We create a Dynamo object with an async get function. The only things we need to make a request are an ID and a table name. We format those into the correct parameter format for the DocumentClient, await a documentClient.get request, and make sure that we add .promise() to the end. This turns the request from a callback to a promise which is much easier to work with. We check that we managed to get an item from Dynamo and then we return that item.

We now have the all the code that we need, we have to update our serverless.yml file too. The first thing to do is to add our new API endpoint by adding it to our list of functions.

    getPlayerScore:
        handler: lambdas/endpoints/getPlayerScore.handler
        events:
            - http:
                  path: get-player-score/{ID}
                  method: GET
                  cors: true

There are two more changes that we need to make to get our endpoint working:

• environment variables
• permissions

You may have noticed in the getPlayerScore.js file we had a line of code like this:

const tableName = process.env.tableName;

This is where we are getting the table name from the environment variables of the Lambda. To create our Lambda with the correct environment variables, we need to set a new object in the provider called environment with a field of tableName and a value of ${self:custom.tableName}. This will ensure that we are making the request to correct table.

We also need to give our Lambdas permissions to access Dynamo. We have to add another field to the provider called iamRoleStatements. This has an array of policies which can allow or disallow access to certain services or resources:

provider:
    name: aws
    runtime: nodejs10.x
    profile: serverlessUser
    region: eu-west-1
    environment:
        tableName: ${self:custom.tableName}
    iamRoleStatements:
        - Effect: Allow
          Action:
              - dynamodb:*
          Resource: '*'

As all this has been added to the provider object, it will be applied to all Lambdas.

We can now run sls deploy again to deploy our new endpoint. When that is done we should get an output with a new endpoint of https://${something-provided-by-API-Gateway}/get-player-score/{ID}. If we copy that URL into a browser tab and add the ID of the player that we created in the last section, we should get a response.

Adding New Data to DynamoDB

Being able to get data from Dynamo is cool, but it's quite useless if we can't also add new data to the table as well. We're going to be creating a POST endpoint to create new data in our Dynamo table.

Embedded content

Start by creating a new file in our endpoints folder called createPlayerScore.js and adding this code:

const Responses = require('../common/API_Responses');
const Dynamo = require('../common/Dynamo');

const tableName = process.env.tableName;

exports.handler = async event => {
    console.log('event', event);

    if (!event.pathParameters || !event.pathParameters.ID) {
        // failed without an ID
        return Responses._400({ message: 'missing the ID from the path' });
    }

    let ID = event.pathParameters.ID;
    const user = JSON.parse(event.body);
    user.ID = ID;

    const newUser = await Dynamo.write(user, tableName).catch(err => {
        console.log('error in dynamo write', err);
        return null;
    });

    if (!newUser) {
        return Responses._400({ message: 'Failed to write user by ID' });
    }

    return Responses._200({ newUser });
};

This code is very similar to the getPlayerScore code with a few changes. We are getting the user from the body of the request, adding the ID to the user, and then passing that to a Dynamo.write function. We need to parse the event body as API Gateway stringifies it before passing it to the Lambda.

We now need to modify the common Dynamo.js file to add the .write method. This performs very similar steps to the .get function and returns the newly created data:

    async write(data, TableName) {
        if (!data.ID) {
            throw Error('no ID on the data');
        }

        const params = {
            TableName,
            Item: data,
        };

        const res = await documentClient.put(params).promise();

        if (!res) {
            throw Error(`There was an error inserting ID of ${data.ID} in table ${TableName}`);
        }

        return data;
    }

We've created the endpoint and common code, so the last thing we need to do is modify the serverless.yml file. As we added the environment variable and permissions in the last section, we just need to add the function and API configuration. This endpoint is different from the previous two because the method is POST instead of GET:

    createPlayerScore:
        handler: lambdas/endpoints/createPlayerScore.handler
        events:
            - http:
                  path: create-player-score/{ID}
                  method: POST
                  cors: true

Deploying this with sls deploy will now create three endpoints, including our create-player-score endpoint. Testing a POST endpoint is more complex than a GET request, but luckily there are tools to help us out. I use Postman to test all my endpoints as it makes it quick and easy.

Create a new request and paste in your create-player-score URL. You need to change the request type to POST and set the ID at the end of the URL. Because we're doing a POST request we can send up data within the body of the request. Click body then raw and select JSON as the body type. You can then add the data that you want to put into your table. When you click Send, you should get a successful response:

To validate that your data has been added to the table, you can make a get-player-score request with the ID of the new data you just created. You can also go into the Dynamo console and look at all the items in the table.

Creating S3 GET and POST Endpoints

Dynamo is a brilliant database storage solution, but sometimes it isn't the best storage solution. If you've got data that isn't going to change and you want to save some money, or if you want to store files other than JSON, then you might want to consider Amazon S3.

Embedded content

Creating endpoints to get and create files in S3 is very similar to DynamoDB. We need to create two endpoint files, a common S3 file, and modify the serverless.yml file.

We're going to start with adding a file to S3. Create a createFile.js file in the endpoints folder and add this code:

const Responses = require('../common/API_Responses');
const S3 = require('../common/S3');

const bucket = process.env.bucketName;

exports.handler = async event => {
    console.log('event', event);

    if (!event.pathParameters || !event.pathParameters.fileName) {
        // failed without an fileName
        return Responses._400({ message: 'missing the fileName from the path' });
    }

    let fileName = event.pathParameters.fileName;
    const data = JSON.parse(event.body);

    const newData = await S3.write(data, fileName, bucket).catch(err => {
        console.log('error in S3 write', err);
        return null;
    });

    if (!newData) {
        return Responses._400({ message: 'Failed to write data by filename' });
    }

    return Responses._200({ newData });
};

This code is almost identical to the createPlayerScore.js code, but uses a filename instead of an ID and S3.write instead of Dynamo.write.

Now we need to create our S3 common code to simplify requests made to S3:

const AWS = require('aws-sdk');
const s3Client = new AWS.S3();

const S3 = {
    async write(data, fileName, bucket) {
        const params = {
            Bucket: bucket,
            Body: JSON.stringify(data),
            Key: fileName,
        };
        const newData = await s3Client.putObject(params).promise();
        if (!newData) {
            throw Error('there was an error writing the file');
        }
        return newData;
    },
};
module.exports = S3;

Again, the code in this file is very similar to the code in Dynamo.js, with a few differences around the parameters for the request.

The last thing we need to do for writing to S3 is change the severless.yml file. We need to do four things: add environment variables, add permissions, add the function, and add an S3 bucket.

In the provider we can add a new environment variable of bucketName: ${self:custom.s3UploadBucket}.

To add permission to read and write to S3 we can add a new permission to the existing policy. Straight after - dynamodb:* we can add the line - s3:*.

Adding the function is the same as we've been doing with all our other functions. Make sure that the path has a parameter of fileName as that is what you are checking for in your endpoint code:

    createFile:
        handler: lambdas/endpoints/createFile.handler
        events:
            - http:
                  path: create-file/{fileName}
                  method: POST
                  cors: true

Lastly we need to create a new bucket to upload these files into. In the custom section we need to add a new field s3UploadBucket and set it to a unique bucket name. We also need to configure the resource. After the Dynamo table config, we can add this to create a new bucket for our file uploads:

        s3UploadBucket:
            Type: AWS::S3::Bucket
            Properties:
                BucketName: ${self:custom.s3UploadBucket}

With this set up it is time to deploy again. Running sls deploy again will deploy the new upload bucket as well as the S3 write endpoint. To test the write endpoint, we'll need to head back over to Postman.

Copy in the create-file URL that you get when Serverless has completed the deployment and paste it into Postman and change the request type to POST. Next, what we need to do is to add the filename that we are uploading. In our case we're going to be uploading car.json. The last thing we need to do is add the data to the request. Select Body then raw with a type of JSON. You can add whatever JSON data you would like but here's some example data:

{
    "model": "Ford Focus",
    "year": 2018,
    "colour": "red"
}

When you post this data up, you should get a 200 response with an ETag reference to the file. Going into the console and your new S3 bucket you should be able to see car.json.

Getting Data from S3

Now that we can upload data to S3, we want to be able to get it back too. We start by creating a getFile.js file inside the endpoints folder:

const Responses = require('../common/API_Responses');
const S3 = require('../common/S3');

const bucket = process.env.bucketName;

exports.handler = async event => {
    console.log('event', event);

    if (!event.pathParameters || !event.pathParameters.fileName) {
        // failed without an fileName
        return Responses._400({ message: 'missing the fileName from the path' });
    }

    const fileName = event.pathParameters.fileName;

    const file = await S3.get(fileName, bucket).catch(err => {
        console.log('error in S3 get', err);
        return null;
    });

    if (!file) {
        return Responses._400({ message: 'Failed to read data by filename' });
    }

    return Responses._200({ file });
};

This should look pretty similar to previous GET endpoints we've created before. Differences are the use of the fileName path parameter, S3.get, and returning the file.

Inside the common s3.js file we need to add the get function. The main difference between this and getting from Dynamo is that when we get from S3, the result is not a JSON response, but a Buffer. This means that if we upload a JSON file, it won't come back down in JSON format, so we check if we're getting a JSON file and then transform it back to JSON:

    async get(fileName, bucket) {
        const params = {
            Bucket: bucket,
            Key: fileName,
        };
        let data = await s3Client.getObject(params).promise();
        if (!data) {
            throw Error(`Failed to get file ${fileName}, from ${bucket}`);
        }
        if (fileName.slice(fileName.length - 4, fileName.length) == 'json') {
            data = data.Body.toString();
        }
        return data;
    }

Back in our serverless.yml file, we can add a new function and endpoint for getting files. We've already configured the permissions and environment variables:

    getFile:
        handler: lambdas/endpoints/getFile.handler
        events:
            - http:
                  path: get-file/{fileName}
                  method: GET
                  cors: true

As we're creating a new endpoint we need to do a full deployment again with sls deploy. We can then take the new get-file endpoint and paste it into a browser or Postman. If we add car.json to the end of the request we'll receive the JSON data that we uploaded earlier in this section.

Securing Your Endpoints with API Keys

Being able to create API endpoints quickly and easily with Serverless is great for starting a project and creating a proof of concept. When it comes to creating a production version of your application, you need to start being more careful about who can access your endpoints. You don't want anybody being able to hit your APIs.

Embedded content

To secure your APIs there are loads of methods, and in this section we're going to be implementing API keys. If you don't pass the API key with the request then it fails with an unauthorised message. You can then control who you give the API keys to, and therefore who has access to your APIs.

You can also add usage policies to your API keys so that you can control how much each person uses your API. This allows you to created tiered usage plans for your service.

To start we're going to be creating a simple API Key. To do this we need to go into our serverless.yml file and add some configuration to the provider.

    apiKeys:
        myFirstAPIKey

This will create a new API key. Now we need to tell Serverless which API endpoints to protect with the API key. This has been done so that we can have some of the APIs protected, whilst some of them stay public. We specify that an endpoint needs to be protected by adding the option private: true:

    getUser:
        handler: lambdas/endpoints/getUser.handler
        events:
            - http:
                  path: get-user/{ID}
                  method: GET
                  cors: true
                  private: true

You can then add this field to as many of your APIs as you would like. To deploy this we can run sls deploy again. When this completes, you will get back an API key in the return values. This is very important and we'll use it very soon. If you try and make a request to your get-user API you should get a 401 Unauthorised error.

To get the request to succeed, you now need to pass up an API key in the headers of the request. To do this we need to use Postman or another API request tool and add header to our get request. We do this by selecting Authorisation using the API type. The key needs to be X-API-KEY and the value is the key that you got as an output from your Serverless deploy:

Now when we make the request we get a successful response. This means that the only people who can access your API are people who you have given your API key to.

This is great, but we can do more. We can add a usage policy to this API key. This is where we can limit the number of requests a month as well as the rate at which requests can be made. This is great for running a SAAS product as you can provide an API key that gives users a set amount of API calls.

To create a usage plan we need to add a new object in the provider. The quota section defines how many requests can be made using that API key. You can change the period to either DAY or WEEK if that would suit your application better.

The throttle section allows you to control how frequently your API endpoints can be hit. Adding a throttle rate limit sets a maximum number of requests per second. This is very useful as it stops people from setting up a denial of service attack. The burstLimit allows the API to be hit more often than your rateLimit but only for a short period of time, normally a few seconds:

    usagePlan:
        quota:
            limit: 10
            period: MONTH
        throttle:
            burstLimit: 2
            rateLimit: 1

If we were to deploy this again, the deployment would fail as we would be trying to deploy the same API key. API keys need to be unique so we have to change the name of the API key. When we deploy this and copy our new API key into Postman, we'll be able to make requests as we normally would. If we try and make too many requests per second or reach the maximum number of requests then we'll get a 429 error of

{
    "message": "Limit Exceeded"
}

This means that you can't use this API key again until next month.

Whilst creating a usage plan is great, you often want to give different people different levels of access to your services. You might give free users 100 requests per month and paying users get 1000. You might want different payment plans which give different number of requests. You would also probably want a master API key for yourself which has unlimited requests!

To do this we can set up multiple groups of API keys that each have their own usage policy. We need to change the apiKeys and usagePlan sections:

    apiKeys:
        - free:
              - MyAPIKey3
        - paid:
              - MyPaidKey3
    usagePlan:
        - free:
              quota:
                  limit: 10
                  period: MONTH
              throttle:
                  burstLimit: 2
                  rateLimit: 1
        - paid:
              quota:
                  period: MONTH
                  limit: 1000
              throttle:
                  burstLimit: 20
                  rateLimit: 10

Once you've saved and deployed this you'll get two new API keys, each with a different level of access to your API endpoints.

Thanks for reading this guide! If you've found it useful, please subscribe to my Youtube channel where I release weekly videos on Serverless and software development.

Serverless architecture is the industry's latest buzzword and many of the largest tech companies have begun to embrace it.

In this article, we'll learn what it is and why you should use it. We'll also set up AWS, create our serverless app, and create a slack app!

What is Serverless?

Serverless is a cloud computing paradigm in which the developer no longer has to worry about maintaining a server – they just focus on the code.

Cloud providers, such as AWS or Azure, are now responsible for executing code and maintaining servers by dynamically allocating their resources. A variety of events can trigger code execution, including cron jobs, http requests, or database events.

The code that developers send to the cloud is usually just a function so, many times, serverless architecture is implemented using Functions-as-a-Service, or FaaS. The major cloud providers provide frameworks for FaaS, such as AWS Lambda and Azure Functions.

Why Serverless?

Not only does serverless allow developers to just focus on code, but it has many other benefits as well.

Since cloud providers are now responsible for executing code and dynamically allocate resources based on event triggers, you typically only pay per request, or when your code is being executed.

Additionally, since cloud providers are handling your servers, you don't have to worry about scaling up – the cloud provider will handle it. This makes serverless apps lower cost, easier to maintain, and easier to scale.

Setting up AWS Lambda

For this tutorial, I will be using AWS Lambda, so first, we'll create an AWS account. I find AWS's UI hard to understand and difficult to navigate, so I will be adding screenshots for each step.

Once you log in, you should see this:

Main screen

Next, we'll set up an IAM user. An IAM (Identity and Access Management) user interacts with AWS and its resources on your behalf. This allows you to create different IAM users with different permissions and purposes, without compromising the security of your root user account.

Click on the "services" tab at the top of the page, and type "IAM" into the bar:

Click on the first result, and you'll see, on the left-hand sidebar, that you're at the dashboard. Click on the "Users" option to get to create our new IAM user.

Click on the "Add user" button to create a new user. Fill in the details as follows:

You can name your user anything you'd like, but I went with serverless-admin. Be sure that your user has "Programmatic access" to AWS, not "AWS Management Console Access". You'd use the latter for teammates, or other humans who need access to AWS. We just need this user to interact with AWS Lambda, so we can just give them programmatic access.

For permissions, I've chosen to attach existing policies since I don't have any groups, and I don't have any existing users that I want to copy permissions for. In this example, I will create the user with Administrator access since it's just for a personal project; however, if you were to use a serverless app in an actual production environment, your IAM user should be scoped to only access Lambda-necessary parts of AWS. (Instructions can be found here).

I didn't add any tags and created the user. It's vital to save the information given to you on the next screen - the Access ID and Secret Access Key.

Don't leave this screen without copying down both! You won't be able to see the Secret access key again after this screen.

Finally, we'll add these credentials to command line AWS. Use this guide to get aws cli setup.

Make sure you have it installed by running aws --version. You should see something like this:

Then run aws configure and fill in the prompts:

I have the default region as us-east-2 already set up, but you can use this to determine what your region is.

To make sure that you have your credentials set up correctly, you can run cat ~/.aws/credentials in your terminal.

If you want to configure a profile other than your default, you can run the command as follows: aws configure --profile [profile name].

If you had trouble following the steps, you can also check out AWS's documentation.

Set up serverless

Go to your terminal and install the serverless package globally using npm: npm i -g serverless. (More info on serverless here)
and your terminal should look something like this:

Next, navigate to the directory where you want to create the app, then run serverless and follow the prompts:

For this application, we'll be using Node.js. You can name your app anything you want, but I've called mine exampleSlackApp.

Open your favorite code editor to the contents in exampleSlackApp (or whatever you've called your application).

First, we'll take a look at serverless.yml. You'll see there's a lot of commented code here describing the different options you can use in the file. Definitely give it a read, but I've deleted it down to just:

service: exampleslackapp

provider:
  name: aws
  runtime: nodejs10.x
  region: us-east-2

functions:
  hello:
    handler: handler.hello

I've included region since the default is us-east-1 but my aws profile is configured for us-east-2.

Let's deploy what we already have by running serverless deploy in the directory of the app that serverless just created for us. The output should look something like this:

And if you run serverless invoke -f hello in your terminal, it'll run the app, and you should see:

{
    "statusCode": 200,
    "body": "{\n  \"message\": \"Go Serverless v1.0! Your function executed successfully!\",\n  \"input\": {}\n}"
}

For further proof that our slack app is live, you can head back to AWS console. Go to the services dropdown, search for "Lambda", and click on the first option ("Run code without thinking about servers").

And here's your app!

Next, we'll explore actually using serverless by building our slack app. Our slack app will post a random Ron Swanson quote to slack using a slash command like this:

The following steps don't necessarily have to be done in the order that I've done them, so if you want to skip around, feel free!

Adding the API to our code

I'm using this API to generate Ron Swanson quotes since the docs are fairly simple (and of course, it's free). To see how requests are make and what gets returned, you can just put this URL in your browser:

https://ron-swanson-quotes.herokuapp.com/v2/quotes

You should see something like this:

So, we can take our initial function and modify it as such:

module.exports.hello = (event) => {
  getRon();
};

and getRon looks like:

function getRon() {
  request('https://ron-swanson-quotes.herokuapp.com/v2/quotes', function (err, resp, body) {
    console.log('error:', err)
    console.log('statusCode:', resp && resp.statusCode)
    console.log('body', body)
  })
}

Now, let's check if it works. To test this code locally, in your terminal: serverless invoke local -f hello. Your output should look something like:

Spoiler: There was a wrong way to consume alcohol

serverless invoke -f hello would run the code that you've deployed, as we saw in previous sections. serverless invoke local -f hello, however, runs your local code, so it's useful for testing. Go ahead and deploy using serverless deploy!

Create your Slack App

To create your slack app, follow this link. It'll make you sign into a slack workspace first, so be sure you're a part of one that you can add this app to. I've created a testing one for my purposes. You'll be prompted with this modal. You can fill in whatever you want, but here's what I have as an example:

From there, you'll be taken to the homepage for your app. You should definitely explore these pages and the options. For example, I've added the following customization to my app:

Display information can be found from the "Basic Information" tab on the app

Next, we need to add some permissions to the app:

To get an OAuth Access Token, you have to add some scope and permissions, which you can do by scrolling down:

I've added "Modify your public channels" so that the bot could write to a channel, "Send messages as Ron Swanson" so when the message gets posted, it looks like a user called Ron Swanson is posting the message, and slash commands so the user can "request" a quote as shown in the screenshot at the beginning of the article. After you save the changes, you should be able to scroll back up to OAuths & Permissions to see:

Click the button to Install App to Workspace, and you'll have an OAuth Access Token! We'll come back to this in a second, so either copy it down or remember it's in this spot.

Connect Code and Slack App

In AWS Lambda, find your slack app function. Your Function Code section should show our updated code with the call to our Ron Swanson API (if it does not, go back to your terminal and run serverless deploy).

Scroll below that to the section that says "Environment Variables", and put your Slack OAuth Access Token here (you can name the key whatever you'd like):

Let's go back to our code and add Slack into our function. At the top of our file, we can declare a const with our new OAuth Token:

const SLACK_OAUTH_TOKEN = process.env.OAUTH_TOKEN.

process.env just grabs our environment variables (additional reading). Next, let's take a look at the Slack API to figure out how to post a message to a channel.

The two pictures above I've taken from the API are the most relevant to us. So, to make this API request, I'll use request by passing in an object called options:

  let options = {
    url: 'https://slack.com/api/chat.postMessage',
    headers: {
      'Accept': 'application/json',
    },
    method: 'POST',
    form: {
      token: SLACK_OAUTH_TOKEN,
      channel: 'general', // hard coding for now
      text: 'I am here',
    }
  }

and we can make the request:

  request(options, function(err, resp, body) {
    console.log('error:', err)
    console.log('statusCode:', resp && resp.statusCode)
    console.log('body', body)
  })

Finally, I'll wrap the whole thing in a function:

function postRon(quote) {
  let options = {
    url: 'https://slack.com/api/chat.postMessage',
    headers: {
      'Accept': 'application/json',
    },
    method: 'POST',
    form: {
      token: SLACK_OAUTH_TOKEN,
      channel: 'general',
      text: quote,
    }
  }

  request(options, function(err, resp, body) {
    console.log('error:', err)
    console.log('statusCode:', resp && resp.statusCode)
    console.log('body', body)
  })
}

and we can call it from getRon like this:

function getRon() {
  request('https://ron-swanson-quotes.herokuapp.com/v2/quotes', function (err, resp, body) {
    console.log('error:', err)
    console.log('statusCode:', resp && resp.statusCode)
    console.log('body', body)
    postRon(body.substring(2, body.length - 2)) // here for parsing, remove if you want to see how/why I did it
  })
}

So our code should all in all look like this:

'use strict';
let request = require('request');

const SLACK_OAUTH_TOKEN = process.env.OAUTH_TOKEN

module.exports.hello = (event) => {
  getRon();
};

function getRon() {
  request('https://ron-swanson-quotes.herokuapp.com/v2/quotes', function (err, resp, body) {
    console.log('error:', err)
    console.log('statusCode:', resp && resp.statusCode)
    console.log('body', body)
    postRon(body.substring(2, body.length - 2))
  })
}

function postRon(quote) {
  let options = {
    url: 'https://slack.com/api/chat.postMessage',
    headers: {
      'Accept': 'application/json',
    },
    method: 'POST',
    form: {
      token: SLACK_OAUTH_TOKEN,
      channel: 'general',
      text: quote,
    }
  }

  request(options, function(err, resp, body) {
    console.log('error:', err)
    console.log('statusCode:', resp && resp.statusCode)
    console.log('body', body)
  })
}

Now let's test! Unfortunately, our environment variable in AWS Lambda isn't available to us when we run serverless invoke local -f hello. There are a few ways you can approach this, but for our purposes, you can just replace the value for SLACK_OAUTH_TOKEN with your actual OAuth Token (make sure it's a string). But be sure you switch it back before you push it up to version control!

Run serverless invoke local -f hello, and hopefully you should see a message like this in your #general channel:

Please note that I put down my channel name as 'general' since it's my test workspace; however, if you're in an actual workspace, you should create a separate channel for testing apps, and put the message there instead while you're testing.

And in your terminal, you should see something like:

If that works, go ahead and deploy it using serverless deploy. If it does not, the best way to debug this is to adjust code and run serverless invoke local -f hello.

Adding slash command

The last and final part is adding a slash command! Go back to your function's home page in AWS Lambda and look for the button that says "Add trigger":

We're going to add an API Gateway (as I already have).

Click on the button to get to the "Add trigger" page, and select "API Gateway" from the list:

I've filled in the information based on defaults mostly:

I've also left this API open for use – however, if you're using this in production, you should discuss what standard protocol would be with your team. "Add" the API, and you should receive an API endpoint. Hold on to this, because we'll need it for the next step.

Let's switch back over to our slack app and add a slash command:

Click on "Create New Command" and it should pop up with a new window to create a command. Here's how I filled mine out:

You can enter anything you want for "command" and "short description" but for "request URL", you should put your API endpoint.

Finally, we'll go back to our code to make some final adjustments. If you try to use the slash command, you should receive some kind of error back – this is because slack expects a response and AWS expects you to give a response when the endpoint is hit. So, we'll change our function to allow a callback (for reference):

module.exports.hello = (event,context,callback) => {
  getRon(callback);
};

and then we'll change getRon to do something with the callback:

function getRon(callback) {
  request('https://ron-swanson-quotes.herokuapp.com/v2/quotes', function (err, resp, body) {
    console.log('error:', err)
    console.log('statusCode:', resp && resp.statusCode)
    console.log('body', body)
    callback(null, SUCCESS_RESPONSE)
    postRon(body.substring(2, body.length - 2))
  })
}

where SUCCESS_RESPONSE is at the top of the file:

const SUCCESS_RESPONSE = {
  statusCode: 200,
  body: null
}

You can put the callback here or in postRon – it just depends on what your purposes are with the callback.

Our code at this point now looks something like:

'use strict';
let request = require('request');

const SLACK_OAUTH_TOKEN = OAUTH_TOKEN

const SUCCESS_RESPONSE = {
  statusCode: 200,
  body: null
}

module.exports.hello = (event,context,callback) => {
  getRon(callback);
};

function getRon(callback) {
  request('https://ron-swanson-quotes.herokuapp.com/v2/quotes', function (err, resp, body) {
    console.log('error:', err)
    console.log('statusCode:', resp && resp.statusCode)
    console.log('body', body)
    callback(null, SUCCESS_RESPONSE)
    postRon(body.substring(2, body.length - 2))
  })
}

function postRon(quote) {
  let options = {
    url: 'https://slack.com/api/chat.postMessage',
    headers: {
      'Accept': 'application/json',
    },
    method: 'POST',
    form: {
      token: SLACK_OAUTH_TOKEN,
      channel: 'general',
      text: quote,
    }
  }

  request(options, function(err, resp, body) {
    console.log('error:', err)
    console.log('statusCode:', resp && resp.statusCode)
    console.log('body', body)
  })
}

You should be able to use the /ron command in slack now and get a Ron Swanson quote back. If you don't, you can use Cloudwatch logs to see what went wrong:

The way our code works now, we've hardcoded in the channel name. But, what we actually want is for the quote to get posted in the message where you used /ron.

So, we can now use the event portion of our function.

module.exports.hello = (event,context,callback) => {
  console.log(event)
  getRon(callback);
};

Use /ron to run the function, and then check your Cloudwatch logs to see what gets logged to the console (you may need to refresh). Check on the most recent logs and you should see something like this:

The first item in this list (where it says "resource", "path", etc.) is the event, so if you expand that, you'll see a long list of things, but what we're looking for is 'body' all the way down at the bottom:

where's waldo: spot the param edition

Body is a string with some relevant information in it, one of them being "channel_id". We can use channel_id (or channel_name) and pass it into the function that creates our slack message. For your convenience, I've already parsed this string: event.body.split("&")[3].split("=")[1] should give you the channel_id. I hardcoded in which entry (3) the channel_id was for simplicity.

Now, we can alter our code to save that string as a variable:

let channel = 'general' (as our fallback)

module.exports.hello = (event,context,callback) => {
  console.log(event)
  channel = event.body.split("&")[3].split("=")[1]
  console.log(context)
  getGoat(callback);
};

and in postRon:

  let options = {
    url: 'https://slack.com/api/chat.postMessage',
    headers: {
      'Accept': 'application/json',
    },
    method: 'POST',
    form: {
      token: SLACK_OAUTH_TOKEN,
      channel: channel,
      text: quote,
    }
  }

Finally, if you use a slack command in any channel in your workspace, you should be able to see a Ron Swanson quote pop up! If not, as I mentioned before, the most common tools I use to debug serverless apps are serverless invoke local -f <function name> and Cloudwatch logs.

Hopefully you were successfully able to create a functioning Slack application! I've included resources and background reading dispersed throughout the article and I'm happy to answer any questions you may have!

Final Repo with code: https://github.com/lsurasani/ron-swanson-slack-app/

The are the 4 areas of development you need to know to call yourself a full-stack developer

Becoming a full-stack developer is the goal of a lot of developers. Being able to create a complete software product, getting to understand how the whole system works, and the very nice wage increase (Over £5,500**) are all reasons people want to level up their skills and become a full-stack developer.

The issue is that learning all of the skills you need can take a lot of time. We’ll cover the 4 areas of development that you need to know, and discuss the best ways that you can learn them.

Front End /Website Hosting

Whenever you build any sort of application, it needs to have a front end. This is what your users will see and how they interact with your product.

This is often the first serverless skill that developers gain, often without realising it. This is often through GitHub pages or a hosting service.

Whilst these services are great for quick and simple project hosting, you will need something more robust for larger and more technical serverless web hosting.

What you’ll need to be able to do

• To be able to host the files required for a front end application.
• To be able to serve these files on a given URL at scale
• Point a registered domain name at these files

How to do this with Serverless?

• Host the files on Amazon S3 (file storage system)
• Create a CloudFront distribution to serve the files at scale
• Use Route 53 to register a domain name and point it at the Cloudfront Distribution

Why Serverless is the best way to do this

S3, CloudFront and Route 53 all scale so you don’t have to work out (guess) how many visitors your site will get

• You don’t need to set up or maintain the servers
• You don’t need to set up DNS, nameservers or anything else to get the site up on your URL. Route 53 handles all of this.

Create an API

Every app needs APIs so that the front end can interact with the back end (databases, storage, email, etc.) which is where most of the power of a full-stack app comes from.

What you’ll need to be able to do

• To be able to create restful API endpoints
• To be able to access your databases
• To be able to access other services (Storage, SMS, email, other APIs)
• Protect your endpoints with API keys

How to do this?

• Use API Gateway to build the API endpoints
• Create Lambda functions to execute your logic and access other services (database access, SMS, email, etc.)
• Create API keys that provide access to your API endpoints

Why Serverless is the best way to do this

• Each endpoint is an isolated function, so if one breaks it doesn’t crash the others
• You have very easy access to the rest of the serverless services through the aws-sdk, reducing code and speeding up development
• You can easily create, limit and remove API keys to make sure that the right people are able to invoke your API endpoints.

Databases

All full-stack services need a way to store data about users, products, and everything else. This might be in a relational or non-relational database but you need to store the data somewhere organised.

What you’ll need to be able to do

• Create a scalable non-relational or relational database
• Access this database

How to do this?

• Create a DynamoDB (non-relational) or Aurora (relational) database
• Access your tables within your API Lambdas using the built-in tools within the AWS SDK

Why Serverless is the best way to do this

• Your tables automatically scale and have built-in redundancy, removing the need to manage and sync multiple copies of databases
• You can easily access the databases with the AWS SDK without having to expose it to the outside world.

Deployment and Maintainance

Once you’ve designed and built all of your systems, you need to deploy them into a production environment, maintain and upgrade them.

What you’ll need to be able to do

• Deploy all of the resources we’ve talked about so far
• Provide version-controlled configuration for all of the resources
• Maintain and update the software and hardware that your systems are running on

How to do this?

• Create the resources using the Serverless framework

Why Serverless is the best way to do this

• When you create your serverless.yml file, you define all of the resources that you need to get your application running
• This serverless.yml file can be version controlled to track changes over time
• You can deploy your whole architecture in minutes with a single command
• All of the underlying software and hardware is maintained, updated and upgraded by your service provider (AWS) so you don’t need to worry about it

If you’ve liked this article and want to start learning how you can become a full-stack developer, I have a free 3 part video course on how to build and deploy your own serverless API.

Check out the course here

** London Front end developer (£42,994) vs London Fullstack Developer (48,767)

Photo by Unsplash

Introduction

A few years ago AWS launched static hosting service S3, which was a paradigm shift for hosting static websites. The tech was crystal clear, all the static assets (HTML, CSS, and JS) would reside in an S3 bucket to host your impressive website. A pretty cool idea I personally liked it, really. Had it not been for that super important contact form hosting on S3 would have been cool but your contact form would be a joke unless you had another server in place to service AJAX requests from that form. The moment you had that service ready, the S3 solution wouldn’t appear so attractive at all.

In the age of cutting edge technology, there’s always jaw-dropping innovations around the corner. One of the awesome tech innovation happens to be serverless. Not that there are no servers involved but you can care less about them now. Serverless can be a proper and viable solution to a lot of problems, it is the most perfect solution for your static hosted contact form. Keep reading by the end of this post you will be able to handle your website forms in the most inexpensive and simplest manner possible.

The Serverless Framework

Source: https://serverless.com/

Serverless is your toolkit for deploying and operating serverless architectures. Focus on your application, not your infrastructure.

— Serverless.com

The Swiss army knife of Serverless technologies. Serverless Framework is a free and open-source web framework written in Node.js. Serverless was the first framework to be developed for building applications exclusively on AWS Lambda, the serverless computing platform provided by Amazon Web Services. Currently, applications developed with Serverless Framework can be deployed to other FaaS service providers. Here is the list of the Serverless cloud services supported by the Serverless Framework:

• AWS Lambda

• Google Cloud Functions

• Azure Functions

• IBM OpenWhisk

• Auth0 Webtask

• Oracle Fn Project

• Spotinst

• Kubeless

Getting started with Serverless Framework

Obviously, you are pretty excited to get started with the Serverless Framework, let’s cut to the chase and start by installing Serverless.

Setting up Serverless is simple. You need to install it through npm and link it to your AWS account.

1. Installing Serverless Globally

Time to get hands-on Serverless stuff.

$ npm install serverless -g

This command installs Serverless globally on your local machine. The Serverless commands are now available to you from your terminal.

Note: Running Linux, you may want to run the above command as sudo.

2. Create an IAM user in the AWS Console

Go to your AWS Console, you will find the IAM service listed below the “Security, Identity & Compliance” group. Inside the IAM dashboard click on the Users tab and click “Add User” button.

AWS IAM Dashboard User Tab

Create a new user and allow the user programmatic access by clicking on the Programmatic access checkbox. Next, in the permissions section, you need to add a set of permissions to the user. From the list of available options under the “Attach existing policies directly” check the AdministratorAccess.

After the user is created, you will have access to the users Access Key ID andSecret Access Key. You will be required to use these keys in the next step.

Word of Caution: These are the kind of credentials you don’t want to lose even by mistake, remember you have provided AdministratorAccess to this user. The user with AdministratorAccess can do pretty much everything with your AWS account.

3. Configuring Serverless to use IAM Credentials

Great! With the keys, you can set up Serverless Framework to access your AWS account. Switch to your terminal and use this command to configure Serverless:

$ sls config credentials --provider aws --key xxxxxxxxxxxxxx --secret xxxxxxxxxxxxxx --profile <username>

Now your Serverless installation knows what account AWS to connect.

Note: sls is an alias for the serverless command. You can use both to the same effect. But sls is kinda cool.

4. Creating a service

With the Serverless Framework hooked up with your AWS account, you can set up a Serverless project in a jiffy. Fire up the terminal and issue the following command:

$ sls create --template aws-python --path <your-folder-path>

The --template flag is used to specify a preset template with the given settings. In the above command the template aws-python will set up the project configured to use AWS as the provider and Python as the runtime. The command will auto-generate serverless.yml , handler.py and .gitignorefile with preset values.

The configuration is defined in the serverless.yml file. This file is the most important file in the Serverless Framework. It’s almost magical, given how it can spin up the infrastructure you have defined in it. The contents of the auto-generated serverless.yml file will look something like this:

service: <your-service-name>

provider:  
  name: aws  
  runtime: python2.7

functions:  
  hello:    
    handler: handler.hello

The provider section defines everything related to the service provider, there are a lot more properties to configure it further you can take a look at them here. In the auto-generated serverless.yml file, you need to add two important tags under the provider section, which are as follows:

region: <your-aws-region>
profile: <aws-username-with-programmatic-access>

The functions property is used to declare the serverless functions, you can declare multiple functions under this property. The above example declares a function called hello present in the handler.py file. Browse over to the handler.py file and you will find something like this:

import json
def hello(event, context):    
    body = {
        "message": "Go Serverless v1.0! Your function executed      successfully!",        
        "input": event    
    }
    response = {
        "statusCode": 200,        
        "body": json.dumps(body)    
    }
    return response

The Serverless App

Our Serverless solution makes use of AWS infrastructure, it consists of API Gateway, Lambda Functions, DynamoDB and Simple Email Service(SES). To achieve this end result we will use the previously introduced Serverless Framework.

Architecture of the Serverless app

• Static Website — Amazon S3 provides a robust and simple web server. All of the static HTML, CSS and JS files for your application can be served from S3. The contact form on our static website is submitted using AJAX.

• API Gateway — The API Gateway is the event source for the application, it acts as a bridge between our contact form and serverless lambda function. It routes the request from the contact form to the lambda function. The API Gateway also performs tasks such as access control, monitoring, API version control and traffic management.

• AWS Lambda — AWS Lambda is the place where the action takes place. Lambda functions run in stateless compute containers that are event-triggered, managed and ephemeral. In our example, we use a lambda function to send email using SES and store the request contents in DynamoDB NoSQL database.

• Simple Email Service (SES) — The cloud-based email sending service from Amazon. Scalable email service, you can send marketing and transactional emails using SES. In our example, we use SES to send emails using a verified email address.

• DynamoDB — DynamoDB provides a scalable, consistent, fully managed and non-relational database from Amazon. In our example, we use DynamoDB to store and retrieve the messages received from the static contact form.

You can find the source code for the demo application here. Go ahead and clone it!

faizanbashir/python-ses-dynamodb-contactform
_python-ses-dynamodb-contactform - Serverless Framework SES and DynamoDB Contact Form_github.com

Application Walkthrough

Let’s have a stroll through the demo application before we actually deploy it on AWS.

1. Demystifying the serverless.yml file

The serverless.yml file defines the services the application needs to use and interact with. The resources and the actions the Serverless functions can perform are listed under the **iamRoleStatements** property. It lists the actions and resources.

iamRoleStatements:
  - Effect: "Allow"
    Action:
      - ses:SendEmail      
      - ses:SendRawEmail    
    Resource: "*"  
  - Effect: "Allow"    
    Action:      
      - dynamodb:Scan      
      - dynamodb:PutItem    
    Resource: "arn:aws:dynamodb:${opt:region, self:provider.region}:*:table/${self:provider.environment.DYNAMODB_TABLE}"

In the serverless.yml we are allowing the Serverless functions to use ses:SendEmail and dynamoDB:PutItem actions among many others defined above.

Since Lambda runs serverless functions in the cloud, we need to define the functions somewhere. Functions are defined using the **functions** property. In our example application we have defined events attached to them.

functions:  
  sendMail:    
    handler: handler.sendMail
    description: Send Email using AWS SES Service
    events:
      - http:          
        path: sendMail          
        method: post          
        integration: lambda          
        cors: true          
        response:            
          headers:              
            "Access-Control-Allow_Origin": "'*'"  

  list:    
    handler: handler.list    
    description: List all the contact form submissions    
    events:      
      - http:          
        path: list          
        method: get          
        integration: lambda          
        cors: true          
        response:            
          headers:              
            "Access-Control-Allow_Origin": "'*'"

Another great feature of Serverless Framework is that it will create an API in the AWS API Gateway and link it with relevant Lambda function. This is done using the http property defined in the events property.

2. Creating Resources

With Serverless Framework you create resources like a DynamoDB table as we have done here. This snippet of code is responsible for creating a DynamoDB table with the given configuration.

resources:  
  Resources:    
    ContactFormDynamoDbTable:      
      Type: 'AWS::DynamoDB::Table'      
      DeletionPolicy: Retain      
      Properties:        
        AttributeDefinitions:          
          -            
            AttributeName: id            
            AttributeType: S        
        KeySchema:          
          -            
            AttributeName: id            
            KeyType: HASH        
        ProvisionedThroughput:          
          ReadCapacityUnits: 1          
          WriteCapacityUnits: 1        
        TableName: ${self:provider.environment.DYNAMODB_TABLE}

3. Peek into the Serverless functions

The demo application is written in python, it uses boto3 AWS SDK to send emails using SES and for performing read/write operations on DynamoDB.

The sendMail function is triggered when a POST request is received from the contact form on the /sendMail path. The list function is triggered by a GET request to /list path defined in the serverless.yml file.

Building the Application

Now that you have set up and configured the Serverless Framework in your machine, it’s time to get things rolling.

1. Clone the application

Let’s start by cloning the application from Github.

$ git clone https://github.com/faizanbashir/python-ses-dynamodb-contactform
$ cd python-ses-dynamodb-contactform

2. Verify e-mail address with SES

Fast-forward to verifying the email you intend to send email from SES. All you need to do is add an email address, AWS will send you a verification with a link to verify the email address.

After verifying the email address, the “Verification Status” for the email will show up as “verified”.

3. Configuring the application

You need to configure the serverless.yml with your account specific details to make it work. Replace the region, profile and SENDER_EMAIL properties in serverless.yml as seen here:

provider:  
  name: aws  
  runtime: python2.7  
  region: <aws-region>  
  profile: <aws-user>  
  ...
environment:  
  SENDER_EMAIL: <verified-email-address>

Awesome! with the configuration done you can turn your attention to deploying the application.

4. Deploying to AWS

Everything in place now you can deploy application with a single command, ain’t that super cool.

$ sls deploy -v

It will take a minute or two to execute if you religiously followed this tutorial, at the end it will provide you a list of endpoints to use for calling our functions. It will look something like this:

endpoints:
POST - https://xxx.execute-api.xx.amazonaws.com/development/sendMail
GET - https://xxxx.execute-api.xx.amazonaws.com/development/list

5. Testing the endpoints

Now that we have the endpoints let’s test application to see if it’s working or not. The /sendMail endpoint expects input in JSON format.

$ curl --header "Content-Type: application/json" \--request POST \--data '{"firstname": "John", "lastname": "Doe", "email": "john@doe.com", "message": "Hi there"}'\https://xxx.execute-api.xx.amazonaws.com/development/sendMail

If the email is sent and the entry written to DynamoDB the request will exit with a response like this.

> "Email Sent!"

Now, let’s test the /list endpoint in the same manner with the GET endpoint you got after deploying the application.

$ curl https://xxxx.execute-api.xx.amazonaws.com/development/list

The /list endpoint response will look something like this:

> {"body": [{"firstname": "John", "lastname": "Doe", "email": "john@doe.com", "updatedAt": 1529425349731, "message": "Hi there", "id": "f651c404-73dc-11e8-bf3e-be54be0b5d22", "createdAt": 1529425349731}], "statusCode": 200}

6. The Contact Form

With the Serverless functions working properly we can go ahead and integrate it into our static contact form. The static form code is in the public folder.

Open the index.html file in your favourite IDE and update the URL variable with the /sendMail endpoint and you are good to go.

//Insert your lambda function URL here
var URL = "https://xxx.execute-api.xx.amazonaws.com/development/sendMail";

Navigate to the page using the file:///<path>/<to>/<folder>/index.html in the browser or upload it to S3 bucket and enable static hosting.

$ aws s3 sync public s3://your-bucket-name

Serverless Contact Form

Treat yourself with a Cappuccino, Latte or . You just implemented a cool way to keep your website on static hosting with handling your forms, thanks to Serverless.

Afterthoughts

Serverless is definitely the way forward, not just for the worlds static contact forms. Serverless has opened a universe of opportunities for you, the contact form was just to get started with. How about using Serverless for your website analytics, a visitor counter or maybe click tracking?

Endless opportunities are waiting for you. Get started for your next project in Serverless, it’ll be an awesome journey.

Originally published at www.serverlessops.io.