DEV Community: Avik Kundu

Introduction to AWS Step Functions

Avik Kundu — Tue, 26 Jul 2022 02:24:13 +0000

AWS cloud provides various services to build serverless applications on their platform. There are compute services like AWS Lambda and AWS Fargate, while there are other integration services which binds various compute services, like AWS Step Functions, Amazon API Gateway, etc.

In this article, we are going to explore AWS Step Functions.

Introduction

The official definition of AWS Step function is as follows:

Step Functions is a serverless orchestration service that lets you combine AWS Lambda functions and other AWS services to build business-critical applications. Through Step Functions' graphical console, you see your application’s workflow as a series of event-driven steps.

One of the most important characteristics of Step functions is that it uses Finite State Machines (FSM) model. The state machines does a simple job of using the states and functions to perform the tasks it is assigned to complete. The use of state machines guarantees the fact of not having the issue of infinite loops, which is itself a costly operation.

The two most important keywords are States and Transitions. A machines gets defined by its states and the relationships between them, known as transitions.
Adding of more states increases the complexity of the FSM. The state machines are defined using the JSON-based Amazon States Language.

When to use Step Functions

The service improves application resiliency in a multitude of ways. For example, developers can implement checkpoints and restarts to ensure application tasks execute in order and as expected. They can use built-in try/catch capabilities to deal with errors and exceptions automatically. And they can even set their own retry handling parameters around backoff rates, max attempts, and error equals.

Furthermore, AWS Step Functions integrates seamlessly with other AWS services. Developers can set it to run in parallel with other tasks, hold for external workflows, or wait for other internal jobs to finish. Users can incorporate machine learning programs into their applications with AWS SageMaker, batch computing capabilities with AWS Batch, serverless ETL through AWS Glue, and much more.

Step Functions are also beneficial for long-running or delayed workflows. It allows you to have a workflow for up to a year while also implementing the waiting state.

Deep-Dive into Step Functions

Types of States

There are 8 types of states:

Task state – Do some work in your state machine. AWS Step Functions can invoke Lambda functions directly from a task state.
Choice state – Make a choice between branches of execution
Fail state – Stops execution and marks it as failure
Succeed state – Stops execution and marks it as a success
Pass state – Simply pass its input to its output or inject some fixed data
Wait state – Provide a delay for a certain amount of time or until a specified time/date
Parallel state – Begin parallel branches of execution
Map state – Adds a for-each loop condition

Important Features

AWS Step Functions allows you to combine your pre-existing Lambda functions and microservices into new compositions while coordinating them. Your workflow's tasks can be executed everywhere, on instances, containers, functions, and mobile devices, among other platforms.
Step Functions maintain a strict barrier between your application's logic and implementation. You can change the order of the steps and add, move, swap, and reshuffle them without altering your business logic.
Whether the operation takes seconds or months to complete, Step Functions automatically manages errors and exceptions with built-in try/catch and retry.
Step Functions maintains service capacity across several Availability Zones in each region and has built-in fault tolerance, ensuring high availability for both the service and the application workflow it supports.
Step Functions automatically scales the operations and underlying compute to run the steps of your application for you in response to changing workloads.
AWS Step Functions has a 99.9% SLA.
AWS Step Functions enables access to metadata about workflow executions so that you can easily identify related resources. This makes it easier to correlate logs for faster debugging and to measure workflow performance data.
It also supports callback patterns. Callback patterns automate workflows for applications with human activities and custom integrations with third-party services.
AWS Step Functions supports workflow execution events, which make it faster and easier to build and monitor event-driven, serverless workflows. Execution event notifications can be automatically delivered when a workflow starts or completes through CloudWatch Events, reaching targets like AWS Lambda, Amazon SNS, Amazon Kinesis, or AWS Step Functions for automated response to the event.

Pricing

Every time a step of your workflow is completed, Step Functions counts a state transition. All of your state machines' combined state transitions, including retries, are counted when calculating your fee.

My Experience at Civo Hackathon 2021

Avik Kundu — Sun, 05 Dec 2021 00:58:18 +0000

Learning Kubernetes has been one of my top priorities this year. I spent quite a lot of time finding good resources to learn and have hands-on experience with the technology.

Finally, I came across Civo Kubernetes, when one of my seniors recommended the platform to me. Yeah, it was the one I was looking for!

The Civo Kubernetes Platform provided me with fully managed K3s clusters as well as high-quality learning videos about Kubernetes from the platform developers themselves. I instantly got a $250 credit in my Civo account once I signed up with my credit card.

Introduction

I am currently in the final year of my Bachelor's degree in Computer Engineering, from KIIT University, Bhubaneswar, India.

In fact, this is my 2nd victory in a nationwide hackathon this year. Earlier this year, I had finished as the First Runners-up at the TCS Inframinds Hackathon. Apart from that, I am currently a DevOps intern at Highradius Technologies and also an enthusiastic open-source contributor.

When I got to know about the Civo Hackathon, I planned to take part in it as I needed hands-on experience with Kubernetes. Also, the speaker line-up before the commencing of the hackathon was interesting. I got to know about the platform as well as about monitoring and profiling from the developer advocates of Civo.

The hackathon spanned over the 2nd weekend of November 2021, starting from Friday, when we had the speaker sessions till Sunday evening. The results were finally announced the very next Monday.

Much to my surprise, I finished up 2nd !!!!!!

My Project

The project I built is a Computer-Aided Diagnostic System that is used to predict whether a person has been infected with COVID-19.

The prediction is possible through the integration of the COVID-19 X-Ray Classifier into a Web Application. By uploading Frontal Chest X-Rays, the model can perform classification between COVID and non-COVID X-Rays using Modified DenseNet architectures.

The users are given the option to save the results to the Database to receive further advice from doctors. The data is stored securely in MongoDB. Apart from that, REST API has been provided for Developers to access the Deep Learning Model and get prediction data in their applications. I have also enabled monitoring facilities for the application.

The entire project was hosted on the Civo Kubernetes Platform.

How I built it

The project kickstarted with the Development of the Web Application. The UI was finalized and then the application was developed. Several open-source styles, libraries and toolkits were used during the development of the Frontend with HTML, CSS and JavaScript.

After completion, the backend of the application was developed with Python & Flask framework. The routes were created and mapped to the Frontend. The Deep Learning Model was integrated with the backend REST APIs. Various libraries such as Numpy, Pillow and Tensorflow was used to manage the model. Finally, MongoDB was integrated with the backend to save the Form data.

This completed the Web Application Development.

The next stage involved deploying the application on Civo K3s Cluster by developing an automated DevOps CI/CD Pipeline. First, the entire application code was pushed to a GitHub repository. Through this step, the code version control is ensured and any change in the code would automatically trigger the entire pipeline.

To deploy applications on K8s, the application needed to be containerized. The building of the Docker container should automatically take place once any code gets changed. After building the container, it needs to be pushed to a Docker Repository, here Dockerhub. Also, the old Docker Image Tag mentioned in the code would need to be replaced by the new Docker Image Tag. For automating all these, a Continuous Integration Pipeline was created with the help of Github Actions as the CI tool.

A workflow file was written to sequence the jobs that needed to be performed, once the code get changed in the repository. The jobs involved building and pushing the Docker container to Dockerhub.
After pushing, the new container tag replaced the older one mentioned in the customization file automatically, with the help of Kustomize.io. The Deployment, Service and Ingress YAML files were pushed to the repository as K8s needed these files during deployment.

Github Actions Workflow file:

name: CIVO HACKATHON WORKFLOW

on: 
  push:
    branches: [ master ]

jobs:

  build:
    runs-on: ubuntu-latest    
    steps:      
      - uses: actions/checkout@v2
      - name: Build and push Docker image
        uses: docker/build-push-action@v1.1.0
        with:
          username: ${{ secrets.DOCKER_USER }}
          password: ${{ secrets.DOCKER_PASSWORD }}
          repository: ${{ secrets.DOCKER_USER }}/civo-hackathon
          tags: ${{ github.sha }}, latest


  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    needs: build

    steps:
    - name: Check out code
      uses: actions/checkout@v2

    - name: Setup Kustomize
      uses: imranismail/setup-kustomize@v1
      with:
        kustomize-version: "3.6.1"

    - name: Update Kubernetes resources
      env:
        DOCKER_USERNAME: ${{ secrets.DOCKER_USER }}
      run: |
       cd kustomize/base
       kustomize edit set image civo-hackathon=$DOCKER_USERNAME/civo-hackathon:$GITHUB_SHA
       cat kustomization.yaml

    - name: Commit files
      run: |
        git config --local user.email "action@github.com"
        git config --local user.name "GitHub Action"
        git commit -am "Bump docker tag"
    - name: Push changes
      uses: ad-m/github-push-action@master
      with:
        github_token: ${{ secrets.GITHUB_TOKEN }}

This completed the Continuous Integration process.

The final stage was to deploy the Docker Image pushed in DockerHub, into a CIVO k3s Cluster. For this, a K3s cluster was created on Civo. Due to CPU intensive nature of the application, the Largest Node configuration was selected. Then through the Civo CLI, the KubeConfig file was connected with the local KubeCTL tool.

Through KubeCTL, a namespace was created and ArgoCD was installed in it. Inside ArgoCD, the configuration was provided to continuously track the GitHub Repository for changes in the Kustomization file.

Since previously through CI, we had managed to update the Kustomization file after a new code change took place, this update in the Kustomization file triggered the ArgoCD to re-deploy the application based on the newer Docker Image Tag provided. Thus after an initial manual Sync, ArgoCD managed to complete the Continuous Deployment process.

The CI/CD Pipeline was successfully created which helped to automatically deploy code changes to production.

After the application was properly working, I proceeded with installing Prometheus and Grafana in a separate namespace in the cluster to fetch and visualize the metrics. For that, I edited the Flask application to make it generate metrics to be fed to Prometheus.

Then I developed a Service Monitor for exposing the metrics endpoint of the application which in turn would be automatically added to the Prometheus Target group. Now, I was able to fetch metrics into Prometheus from the Web application. After that, I set up the Grafana Dashboard to visualize the metrics.

This finally concluded the project.

My Experience

Overall, I had a great experience learning and executing new things within a short span of time. The process of deployment could not be made smoother without the Civo Platform. The fact that we can launch a cluster within a few minutes, along with having a marketplace from where we can pick services we want to preinstall in the cluster, really simplified the process for newbie Kubernetes developers like me.

Apart from that, the presence of the Kubernetes academy which contains beginner-friendly videos about all the different features of K8s, integrated into the platform, helped me to quickly navigate and get my doubts cleared before applying stuff on my cluster.

And of course, we had the option of directly contacting the Civo team via Slack to get out queries resolved. Special thanks to Saiyam Pathak, for his Monitoring video, which really helped me set up the monitoring stack easily.

What's next for the project

Although I tried my best to incorporate all the domains of DevOps into my application, still there are some places that need attention.

First and foremost, I tried to incorporate the GitOps principle as much as possible, which included pushing the application code, Kubernetes Manifests as well as Terraform scripts to the Git. But still, there were some settings that I had to manually set inside the cluster like setting up the ArgoCD. Since ArgoCD supports GitOps, I would be declaring the settings from Git itself.

Apart from that, I would be incorporating some Logging and Profiling tools in the cluster, that would give a better picture of the application deployment.

Last but not the least, the model which has been deployed can currently perform classification only. But recently, in some researches, it has been proved that through Instance Segmentation on the X-Rays, we can actually measure the severity of the spread of the virus by precisely identifying the locations of the GGOs. In the future, I want to integrate such a model with the application, so that users can also measure the severity of the virus instantly.

You can visit the repository from below:

Lucifergene / civo-hackathon

COVID-19 Prediction Powered by AI

COVID-19 PROGNOSIS

COVID-19 Prediction Powered by AI

Website : Heroku Deployment
DockerHub : avik6028/civo-hackathon:latest

Abstract

The project is a Computer-Aided Diagnostic System which is used to predict whether a person has been infected with COVID-19. The prediction is possible through the integration of the COVID-19 X-Ray Classifier into a Web Application. By uploading Frontal Chest X-Rays, the model can perform classification between COVID and non-COVID X-Rays using Modified DenseNet architectures.

The Deep Learning Model used, is open-sourced under MIT License and can be found here.

This project involves an Web Application with an automated pipeline for Continuous Integration and Deployment on CIVO K3s Cluster. K3s is a highly available, certified Kubernetes distribution designed for production workloads in unattended, resource-constrained and remote locations.

Hackathon Theme

Machine Learning

Development Tools Used

Python-Flask
Docker/ DockerHub
Kubernetes/ K3s
Kustomize
GitHub Action CI
Argo CD
MongoDB
CIVO
Postman

Libraries Used

Tensorflow
PyMongo
Numpy
…

View on GitHub

Demo : https://covid-predictioned.herokuapp.com/

DevPost : https://devpost.com/software/covid-19-prognosis

Civo - https://www.civo.com/

You can reach out on my Twitter, Instagram, or LinkedIn if you need more help. I would be more than happy.

If you have come up to this, do drop an ❤️ if you liked this article.

Deploying React Application on Web using AWS Amplify

Avik Kundu — Tue, 09 Nov 2021 21:45:44 +0000

Today, the majority of businesses have switched to cloud computing and are willing to take a chance. Amazon Web Options (AWS) cloud platform is often regarded as the best among the several cloud adoption services currently offered. Over 90 services and products that are intended to assist developers in building quick, dependable, serverless, and secure web and mobile applications are now part of Amazon's constantly expanding portfolio.

Introduction

AWS Amplify is a full suite of tools and services created to make it simple for developers to build and release apps. It was introduced in 2017. Additionally, it might have ready-to-use components, code libraries, and a built-in command-line interface (CLI). The ability to swiftly and securely integrate a variety of tasks, from API to AI, is this tool's most important asset.

The user experience is another factor in the introduction of AWS Amplify. User experience is the most crucial factor that must be taken into account while creating any programme. The user experience across many platforms, including online and mobile, was intended to be unified through AWS Amplify.

Amplify effortlessly scalable with your business from thousands of users to tens of millions of users and covers the entire mobile application development workflow from version control and code testing to production deployment.

The open source Amplify libraries and CLI, which are a component of the Amplify framework, provide a pluggable interface that you may personalise and develop your own plugins for.

Benefits

Don't reinvent the wheel; instead, concentrate on your business. Why create your own authentication system when there are already ones out there that can handle MFA, social providers, and all business features?
Use Amplify to prototype cool ideas and discard features one at a time if necessary. Why not take advantage of the high-quality proof of concept work Amplify makes possible? As an illustration, you could construct your API using produced AppSync resolvers and then gradually replace them with custom resolvers as needed (similarly to Create React App).
Solid DevOps requires good multi-environment design. On-the-fly bootstrapping of new environments is possible. Additionally, the amplification environments can use the same git procedure.

Getting Started

In this article, you will be seeing how we can easily deploy any web application on AWS Amplify. For example, here we are going to deploy a React Application. The source code can be found on the following Github link.

Pre-requisites

an AWS account (of course 🤪)
Node.JS installed in your system
a Github Account and Git CLI installed in your system
Code Editor of your choice (VSCode preferred)

Cloning and Testing the Application Locally

First, we are going to clone the repository and run the application locally in our system. Create a directory in your system and open it with VSCode. You can use the in-app command terminal to execute the code snippets.

To start, clone the repository with the following command:

git clone https://github.com/aditya-sridhar/simple-reactjs-app

Once the repository is cloned, you will see a new directory inside the folder. Navigate inside the directory and type the following commands:

npm install

This will install all the dependencies required to run the application, in your system.

Once completed, you can run the application with the following command:

npm start

The web browser will pop up and you will be seeing the following page:

Thus, we have successfully cloned and tested the application in our local system.

Pushing the application code to your Github Account

Now, we have to upload the code to your Github account, so that you can use the code with AWS Amplify. For creating a repository, we are going to use the Github CLI.

First, delete the .git folder present in the root directory.

Then, initialize the directory with the following command:

git init

After that, lets create a repository with the Github CLI. Type the following command:

gh repo create aws-react-hosting

This will create a repository in your Github Account. Finally. we will be pushing the codes in this repository.

git add .
git commit -m "First Commit"
git remote add origin <link-to-your-github-repo>
git push -u origin main

Deploying on AWS Amplify

Now let's move on to deploy the application to AWS Amplify.

Open the AWS HomePage.
Login and visit the Console.
Select AWS Amplify from the List.
You will reach to the following page:
Select GitHub from the Options available.
Authorize the connection and select the repository you had created earlier.
Click Next and Save and Deploy.
Finally, you will come to the following page:
Once all the stages are completed, click on the link to see the live website.

Thus, we have successfully deployed a React application on AWS Amplify!!!

Conclusion

For web and mobile developers, Amazon Web Services Amplify can be quite helpful. For full-stack apps, all built-in authentication, alerts, and APIs may be implemented with a minimum of effort. Giving your clients the best value instead of wasting time managing the application infrastructure allows you to concentrate on your top priorities.

CloudFlare URL Shortener

Avik Kundu — Sat, 28 Aug 2021 16:42:01 +0000

CloudFlare Worker Script to setup URL Shortener Service

You can optionally add your own aliases. If not, an random string would be assigned.

You need to paste this script in the Index.JS file of your CloudFlare Worker

The Service : https://short-linker.lucifergene.workers.dev/

You can visit the repository from below:

Lucifergene / Cloudflare-URL-Shortener

👷 Cloudflare URL Shortener

index.js is the content of the Workers script.

Wrangler

To generate using wrangler

wrangler generate projectname https://github.com/Lucifergene/Cloudflare-URL-Shortener

Further documentation for Wrangler can be found here.

View on GitHub

You can reach out on my Twitter, Instagram, or LinkedIn if you need more help. I would be more than happy.

If you have come up to this, do drop an ❤️ if you liked this article.

Building Serverless URL Shortener Service on AWS

Avik Kundu — Mon, 23 Aug 2021 16:21:58 +0000

Walk-through of a serverless implementation of an URL Shortener Service without AWS Lambda Functions

The AWS Serverless Ecosystem

Serverless is a way to describe the services, practices, and strategies that enable you to build more agile applications so you can innovate and respond to change faster. With serverless computing, infrastructure management tasks like capacity provisioning and patching are handled by AWS, so you can focus on only writing code that serves your customers.

Serverless Computing = FaaS [Functions as a Service] + BaaS [Backend as a Service]

Serverless Services of AWS:

Compute: AWS Lambda, AWS Fargate
Storage: Amazon DynamoDB, Amazon S3, etc.
Application Integration: Amazon API Gateway, etc.

Introduction

In this walkthrough, we are going to develop an URL Shortener Service using various services of the AWS Serverless Ecosystem. We are going to focus mainly on the backend of the application.

To implement our project in a simplified way, we will use only the 2 most important services: the API Gateway and DynamoDB.

Architecture Diagram

AWS Lambda

AWS Lambda is a serverless compute service that lets you run code without provisioning or managing servers, creating workload-aware cluster scaling logic, maintaining event integrations, or managing runtimes. With Lambda, you can run code for virtually any type of application or backend service ΓÇö all with zero administration.

In this application, we are not going to use AWS Lambda, since our application runs on simpler logic ΓÇö i.e. to store short-URLs into the Database and re-direct to the long-URLs once we call the short-URL.

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 any scale. APIs act as the ΓÇ£front doorΓÇ¥ for applications to access data, business logic, or functionality from your backend services.

In our application, we are going to utilize the functionality of the API Gateway through which we can perform ETL operations during the transit of data between the API Gateway and DynamoDB.

Amazon DynamoDB

Amazon DynamoDB is a key-value and document database that delivers single-digit millisecond performance at any scale. ItΓÇÖs a fully managed, multi-region, multi-active, durable database with built-in security, backup and restores, and in-memory caching for internet-scale applications.

DynamoDB can handle more than 10 trillion requests per day and can support peaks of more than 20 million requests per second.

Getting Started

To follow this project, you only need to have an AWS account. The entire application would be developed within the AWS Web Console.

Let's understand the workflow of the application. We are currently focussing on 2 main features prevalent to all URL-Shorteners.

1. Storing the Short-URL, Long-URL and owner inside DynamoDB

In the backend, once a user sends a POST request to the Route, with all the required parameters, the API Gateway receives the data, transforms it and pushes it into the DynamoDB.

2. Redirecting to the Long-URL once the short-URL is hit

Once a user mentions the short-URL in the HTTP header, the API gateway receives the data, processes it and searches it inside DynamoDB. Once the corresponding Long URL is found, the API Gateway redirects to the Long URL.

Setting Up DynamoDB Database

First of all, we need to configure our Database. For that, we need to create a Table.

The table would be consisting of 3 Columns: longURL , shortId , owner . We would be using the shortId attribute as the Primary key of the table.

In the configuration, please use the exact names mentioned.

Table Name: URL-Shortener
Primary Key: shortId
Table settings: Use Default Settings

Once you create the Table, you would land on the following page mentioning all the Table Details:

Setting up the API Gateway

This is the most important service in our architecture. Through this service, we are going to perform multiple operations.

Create API Endpoints for GET and POST requests.
Transform request parameters received from the API into DynamoDB understandable format.
Convert the response received from the DynamoDB into a format understandable by browsers for re-direction.

We need to create an API of the type Rest API from the API Gateway console.

After selecting the REST-API Gateway type, we need to select the following configurations.

Protocol: REST
Create a new API: New API
API name: URLShortener

This would create a new API.

API Gateway Console

Now, we need to create an New Resource under the / route. The name of the resource is set as: url-shortener .

Under this resource, we need to create multiple methods for **GET **and **POST **requests.

Setting Up POST Request

Under the /url-shortener resource, we need to create a method named ΓÇ£POSTΓÇ¥. In this method, we are going to modify our POST request.

Once the POST Method is selected, we have to use the following information during its setup:

Integration type: AWS Service
AWS Region: ap-south-1 [region where the DynamoDB Instance would be running]
AWS Service: DynamoDB
HTTP method: POST
Action: UpdateItem
Execution role: [ IAM Role in which DynamoDB write permissions are given ]

Once the setup is completed, we land on the following page:

Now, we need to transform the request parameters received from the client into something that would be understood by DynamoDB.

For this, we are going to utilize the Integration Request feature of the API Gateway. Through this feature, we are going to add a Mapping Template based on which the transformation would take place.

On clicking the Integration Request from the above page, we would be landing on the following page:

Under the Mapping Templates section, we need to add the following code:

Now, we have set up the process through which data would be saved into the DynamoDB. But now, we have to also format the Response that DynamoDB would be sending, to a format understandable by the Client.

For this, we need to set up another Mapping Template in the Integration Response section.

Under the Mapping Templates section, we need to add the following code:

Once this is set up, the response of the DynamoDB would be converted in a form understandable by the client.

Thus, we have set up our POST request, which would save the request parameters in the DynamoDB and would send the response back to the client. To test, we need to click on the **TEST **option from the above console.

In the Request Body, we need to type the following:

{
  "longURL": "[https://www.google.co.in](https://www.google.co.in)",
  "owner": "Avik",
  "shortURL": "Google"
}

On submitting the above JSON, we must receive a 200 Status code and a similar response body as the following. Thus we have successfully saved the contents to the DynamoDB.

Setting Up GET Request

The GET request is somewhat different from the POST request. Here, the user would be appending the short URL to the API endpoint. This shortURL would be sent to the DynamoDB by the API Gateway to perform the search operation. Once the associated long URL is found, the API Gateway automatically re-directs to the long URL.

Under the /url-shortener resource, we create another resource named as {shortURL}, which would be having a dynamic resource path, as it is the place where the short URLs would be appended.

Inside the newly created sub-resource, we create the GET request with the following settings:

Integration type: AWS Service
AWS Region: ap-south-1 [region where the DynamoDB Instance would be running]
AWS Service: DynamoDB
HTTP method: POST
Action: GetItem
Execution role: [ IAM Role in which DynamoDB write permissions are given ]

Once the setup is completed, we land on the following page:

Now, we have to perform 3 transformations while the data would be transferred back and forth between the API Gateway and DynamoDB.

A. Integration Request

First, we need to transform the request parameters received from the client into something that would be understood by DynamoDB. For this, we are going to utilize the Integration Request **feature of the API Gateway. Through this feature, we are going to add a **Mapping Template based on which the transformation would take place.

On clicking the Integration Request from the above page, we would be landing on the following page:

Under the Mapping Templates section, we need to add the following code:

B. Method Response

We know that for URL redirections, 302 HTTP Status code is used. Therefore in the response header, we need to set the appropriate status code since by default 200is** **set.

In the Method Response section, we need to delete the 200 status code association and add the 302 HTTP Status Code. To instruct the API gateway to redirect to the URL set in the Location key in the Response header, we need to add it to the corresponding 302 Response Header.

C. Integration Response

After setting up the Method Response, now, we have to also format the Response that DynamoDB would be sending, to a format understandable by the Client.

For this, we need to set up another Mapping Template in the Integration Response section.

Under the Mapping Templates section, we need to add the following code:

Thus, we have set up our GET request, which would redirect the short URL to the actual LongURL after fetching it from DynamoDB.

To test, we need to click on the TEST option from the above console. In the {shortId} field, we need to enter the shortId of the URL and click on the TEST button.

Thus we have received a 302 response code and upon studying the response header, we see a location key that contains the actual Long URL.

And we reached the end of the solution!!!

You can visit the repository from below:

Lucifergene / Serverless-URL-Shortener

Serverless URL Shortener

A simple serverless URL shortener built using API Gateway, DynamoDB and optionally Lambda functions

The beauty of serverless is the ability to build things fast, at the lowest price and the least efforts. AWS API Gateway can be leveraged to

Shortener With Lambda Functions:

Shortener Without Lambda Functions:

A repo inspired from Eric Johnson's repo.
Slide deck for the presentation - konf.me/presentation

View on GitHub

You can reach out on my Twitter, Instagram, or LinkedIn if you need more help. I would be more than happy.

If you have come up to this, do drop an ❤️ if you liked this article.

Good Luck 😎 and happy coding 💻