Search for a command to run...
👋 Hi, I’m @hpfpv ☁️ I’m a Cloud Infrastructure Architect | 8x AWS Certified 🚀 I build secure, scalable, and automated solutions on AWS using Terraform, CloudFormation, and CI/CD 📚 Always exploring hybrid cloud, serverless, and AI-driven architectures
Loved the blog post. I tried to re-create app using your github repo and realized both backend services are dependent on each other. If I deploy main-service using sam deploy, it throws error about attachments-service resource being not available. If i deploy attachments-service, it complains about main-service cognito and few other resources not available. I am bit new to SAM , and coding. Can you tell me how to avoid CF import/export errors to be able to test and deploy this app ?
Hi Mark. Thanks for your comment. You are right. Before deploying the main service, you will need to comment lines 123 to 126 from the template file. It refers to the deleteTodo function which will delete all resources about a todo item including the attachments files. Hope this helps. Feel free to tell me the outcome. Thanks
H. Pierre-Francois I did comment out lines 123 to 126 from main-service template file. Still the stack rolls back with error.I am getting error below :
ROLLBACK_IN_PROGRESS AWS::CloudFormation::Stack todo-houessou-com No export named todo-houessou-com-attachments-service-TodoFilesTable found.
Mark Snow Oops. Comment lines 100-101 as well. Do not forget to update and redeploy the main service CF stack after you deploy the attachment service resources.
H. Pierre-Francois Thanks for quick reply. unfortunately, now it throws out new set of errors related to some missing property values. would appreciate if u write few lines below this post on how to deploy app. I am kind of stuck.
Mark Snow I've just updated the template file in the Github repo. The issue was about resource tags. I remember I wanted to add tags to resources created by the stacks but failed to get the right syntax for CF. Try again and let me know. I will take some time to update the blog post with deployment instructions. Thanks
Very impressive:
All you're missing is a video tutorial and you'd be a serverless hero!
Thank you so much!! I guess I am too shy to make a video but I appreciate your suggestion.
Hi guys! So a few months ago I was helping out on a public-sector AWS Landing Zone, and one day the leadership team came to me with what sounded like a small request. They wanted one document that sum
TL;DR: I shipped a Bedrock Agent todo chatbot and then found I could read another user's todos via prompt injection. The fix that mattered most: promptSessionAttributes is a hint, not enforcement — re
A Bedrock Agent, a WebSocket, and the parts I had to figure out along the way
How we exposed AWS services to on-premises networks with overlapping CIDRs
A journey through the evolution of AI-Infrastructure integration
Hi guys! In this post, we'll be building a sample todo app on AWS with Python. We will build a web application which enables logged in visitors to manage their todo list. We will use the AWS Serverless Application Model SAM Framework to deploy the backend services (API, Lambda, DynamoDB and Cognito) and will host the frontend on S3 behind a CloudFront distribution. The frontend is pretty basic with no fancy visuals (I am no frontend dev :p). We will try to focus on how the resources are created and deployed on AWS.
I will go through the overall setup of the app and how I deployed it. Mostly this will be a theoretical post but all the code can be found in the GitHub repo.
Before I go into the architecture, let me describe what the app is about and what it does. The app is a todo list manager which helps a user manage and track his/her todo list along with their files or attachments. The user can also find specific todos through the search.
The image above should describe the app's basic functionalities.
User/Login Management
Users are able to log in to the app using provided credentials. There is a self-register functionality and once a user is registered, the app provides a capability for the user to log in using those credentials. It also provides a logout option for the user.
Search Todo
Users are able to perform a keyword search and the app shows a list of todos that contain that keyword in the name. The search only searches on todos that the logged-in user has created. So it has the access boundary and doesn’t show Recipes across users.
Add New Todo
Users can add new Todos to be stored in the app. There are various details that can be provided for each Todo. Users can also add notes for each Todo.
Support for files
Users can upload todo files for each Todo. The app provides a capability where users can select and upload a local file or download existing files while adding notes to a Todo. The file can be anything, from a text file to an image file. The app stores it in an S3 bucket and serve it back to the user via CloudFront.
Now that we have a basic functional understanding of the app, let's see how all of these functionalities translate to different technical components. The below image should provide a good overview of each layer of the app and the technical components involved in each layer.
Let's go through each component:
Frontend
The Front end of the app is built of simple HTML and Javascript. All operations and communications with the backend are performed via various REST API endpoints.
Backend
Backend for the app is built with Lambda Functions triggered by REST APIs. It provides various API endpoints to perform application functionalities such as adding or deleting todos, adding or deleting todo files, etc. The REST APIs are built using API Gateway. The API endpoints perform all operations of connecting with the functions, authenticating, etc. CORS is enabled for the API so it only accepts requests from the frontend.
Data Layer
DynamoDB Table is used to store all todos and related data. The lambda functions will be performing all Database operations connecting to the Table and getting requests from the frontend. DynamoDB is a serverless service and it provides auto-scaling along with high availability.
Authentication
The authentication is handled by AWS Cognito. We use a Cognito user pool to store users' data. When a user logs in and a session is established with the app, the session token and related data are stored at the FrontEnd and sent over the API endpoints. API Gateway then validates the session token against Cognito and allow users to perform application operations.
File Service
There is a separate service to handle file management for the application. The File service is composed of Javascript function using AWS SDK (for upload files operations), Lambda functions + API Gateway for API calls for various file operations like retrieving file info, deleting file, etc, S3 and DynamoDB to store files and files information. The files are served back to the user through the app using a CDN (Content Delivery Network). The CDN makes serving the static files faster and users can access/download them faster and easier.
Now that we have some information about the various components and services involved in the app, let's move on to how to place and connect these different components to get the final working application.
The static HTML, JavaScript, and CSS files generated for the website will be stored in an S3 bucket. The S3 bucket is configured to host a website and will provide an endpoint through which the app can be accessed. To perform better on the frontend, the S3 bucket is selected as an Origin to a CloudFront distribution. The CloudFront will act as a CDN for the app frontend and provide faster access through the app pages.
All the backend logic is deployed as AWS Lambda functions. Lambda functions are totally serverless and our task is to upload our code files to create the Lambda functions along with setting other parameters. Below are the functions which are deployed as part of the backend service:
Todos Service
Files Service
To expose the Lambda functions and make them accessible by the Frontend, AWS API Gateway is deployed. API Gateway defines all the APIs' endpoints and routes the requests to the proper Lambda function in the backend. These API gateway endpoints are called by the frontend. Each application service has its own API (keeping services as separate as possible for decoupling purpose) with deployed routes as follow:
Todos Service
Files Service
The addTodoFiles API route triggers the addTodoFiles function which only records the file information like fine name and file path/key to a DynamoDB table. The same table is queried by the getTodoFiles function to display returned files information. The actual operation to upload the files to S3 is performed by a Javascript function in the Frontend code. I found it better to do it that way to prevent a large amount of data going through the lambda functions and thus increasing response time and cost.
DynamoDB tables are used to serve as databases. We have two tables for respectively the Todos Service and the Files Service. The search functionality of the app is handled by simple DynamoDB query requests. We can deploy a DynamoDB Accelerator in front of the tables to increase performance if needed. Below is the configuration of the tables:
Todos Service To keep things simple, each document in DynamoDB will represent one todo with attributes as follow:
Files Service
To support the file management capability of the application, file storage needs to be deployed. I am using an S3 bucket as the storage for the files which are uploaded from the app. The file service API calls the AWS S3 API to store the files in the bucket. To serve the files back to the user, a CloudFront distribution is created with the S3 bucket as the origin. This will serve as the CDN to distribute the static files faster to the end users.
The application backend services are defined as SAM templates. Each service has its own template and resources are configured to be as independent as possible. I am using automated deployments for the whole application environment - frontend and 2 backend services. Each service is deployed using a separate deployment pipeline to maintain optimal decoupling. The components below are used as part of the deployment pipeline:
FrontEnd
Backend
Hopefully, I was able to describe in detail the system architecture which I would use for a basic todo-list management app. This application is designed solely for training purposes and there is a lot of room for improvement. I will continue working on making the deployment more secure, highly available, and fault tolerant. This post should give you a good idea about how to design a basic full stack and fully serverless architecture for an app using the microservices pattern.