AWS API Gateway CRUD REST API

The Challenge

Build a Serverless Framework REST API with AWS API Gateway which supports CRUD functionality (Create, Read, Update, Delete) *don't use service proxy integration directly to DynamoDB from API Gateway

Please use GitHub Actions CI/CD pipeline, AWS CodePipeline, or Serverless Pro CI/CD to handle deployments.

You can take screenshots of the CI/CD setup and include them in the README.

The CI/CD should trigger a deployment based on a git push to the master branch which goes through and deploys the backend Serverless Framework REST API and any other resources e.g. DynamoDB Table(s).

Requirements

0. All application code must be written using NodeJS, Typescript is acceptable as well

1. All AWS Infrastructure needs to be automated with IAC using Serverless Framework

2. The API Gateway REST API should store data in DynamoDB

3. There should be 4-5 lambdas that include the following CRUD functionality (Create, Read, Update, Delete) *don't use service proxy integration directly to DynamoDB from API Gateway

4. Build the CI/CD pipeline to support multi-stage deployments e.g. dev, prod

5. The template should be fully working and documented

6. A public GitHub repository must be shared with frequent commits

7. A video should be recorded (www.loom.com) of you talking over the application code, IAC, and any additional areas you want to highlight in your solution to demonstrate additional skills

Please spend only what you consider a reasonable amount of time for this.

Optionally

Please feel free to include any of the following to show additional experience:

1. Make the project fit a specific business case e.g. Coffee Shop APIs vs Notes CRUD directly from AWS docs
2. AWS Lambda packaging
3. Organization of YAML files
4. Bash/other scripts to support deployment
5. Unit tests, integration tests, etc

Cloathing retail store APIs

Given my background in luxury clothing retail i've decided to create a set of APIs that can be used to manage the products in the store.

Infrastructure

The infrastructure is divided in two stacks, for more flexibility and control over the resources.

Dynamodb table

The table structure is a simplified and ideal version of a clothing product. Is as follows:

Key	type	notes	Keytype
sku	string	the sku of the product	HASH
title	string	the title of the product
description	string	the description of the product
price	decimal	the price of the product
available	boolean	if the product is available
category	string	the category of the product
brand	string	the brand of the product
material	string	the material of the product
tags	list	list of the tags to assign to the product on the store
sizes	list of maps	the sizes and relative quantities of the product
images	list of maps	the images of the product, containing url and alt text
created_at	string	the datetime the product was created in ISO format
updated_at	string	the datetime of the latest update on the product in ISO format

API Gateway

The API gateway has the following endpoints:

metod	path	description	parameters
POST	/createProduct	Create a new product	All info for the product
DELETE	/deleteProduct/{sku}	delete a product	none
PUT	/updateProduct	update a product	all info for the product
GET	/readProducts/{sku}	get a specific product	none
GET	/readProducts	get the first 100 products	none

---

Testing

For testing I've decided to create some E2E tests. They are more complete and allow me to verify that everything is working proprely. In a production enviroment I would have created unit tests and integrations tests, however given the time limit I've chose to go for the E2E only. The tests are written using jest

CI/CD

For the CI/CD. I've used github action to create a continuous deploy workflow, it creates and deploys the stack on AWS with the enviroment of the branch it is pushed on. For better control I've decided to only allow the actual deploy if the commit comment is "deploy", in my opinion this gives better control over the deployiment of the resources, allowing us to make ajustments without having to push them on AWS. Furthermore it is possible to destroy a given enviroment by committing with the comment "destroy", in this case, for simplicity, I've decided not to add any particular measure to prevent accidentally destroying the stack, even though in a production enviroment create policies or procedures to prevent accidentally destroying the infrastructure is not only possible, but encouraged. It is noted that for the deploy or destroy the commit comment must be only "deploy" or "destroy". The pipeline works as follows:

• Check out the code
• Set up node
• install serverless framework and the dependencies
• IF "destroy" is passed as a comment, destroy the infrastructure
• IF "deploy" is passed as a comment, deploy the infrastructure
  • run the tests

Video description of the solution

https://www.loom.com/share/dbefee53ff204ec89b9135a0f0ddca73?sid=cfd4009c-25f8-4ab2-a3e9-044beecfa06a