Simple Leave Management System with AWS Serverless

Table of Contents

Intro
#

In this project, I will discuss how you can build a simple leave apply/approval system using AWS Serverless services.

These are the main functionalities of this implementation.

And below services/functionalities are in use in this project:

CreateLeave Lambda function accepts leave requester’s email, leave approver’s email, leave dates and reason and is responsible to validate and save it to the DyanmoDB table.
Lambda function url is enabled for CreateLeave Lambda function.
Simple web form is created to simulate creation of leave request which is hosted using Amplify Web Hosting.

When a leave request is saved into the DynamoDB table, using DynamoDB steams, Init Lambda function is triggered.
Here, event source mapping is enabled with filtering, so that only the event type INSERT, record type ’leaveRequest’ and record status ‘pending’ will trigger the lambda function.
This Init Lambda function’s only responsibility is to format the input and start new Step Function execution.
Within step function first step is to send a email notification to the leave applicant to inform the receipt of the request. For this, Step function SDK integration for SES v2 is used.
Next, there are 2 branches runs parallel. One for leave reject/approval flow, and the other is to remind the approver about leave request until being processed.

In the leave reject/approval flow, first an email will be send to the approver with the leave information and link to mark the leave as approved or rejected. This step has wait for the task token option enabled.
This link is generated as the function url of the LeaveApproveOrReject Lambda function.
Also, this link consist of the task token generated in the step, so in the LeaveApproveOrReject Lambda function, based on the reject/approval selection, it can call sendTaskSuccess or sendTaskFailure APIs.
If the leave is approved with sendTaskSuccess, then the record in the DynamoDB table will be updated using the Step function SDK integration for DynamoDB.
If the leave is rejected with sendTaskFailure, then there is an additional step to transform the error object before update the record in the DynamoDB table.
As the final step of that branch, an email will be sent to the applicant with the outcome of the processed leave request.

In the other branch, it starts with a wait status which has a pre-configured wait time before sending the reminder.
After the wait time, it checks the status of the leave request using Step function SDK integration for DynamoDB.
Then it checks if the leave request status is pending.
If the status is pending, it sends an email to the approver reminding the leave request using Step function SDK integration for SES v2.
And the flow goes back to the wait step in order to retry later.
If the leave request is not in pending status, it goes into a Pass step to conclude the flow there.
With this, until the leave request is being processed, a reminder will be sent to the approver in regular interval defined by the wait time.

This project is implemented using AWS CDK v2. Source code of this application is available at https://github.com/pubudusj/simple-leave-management

Clone the repository.
Update the Makefile with the sending email for SES and AWS CLI profile (if required).
Run make build to install required dependancies.
Run make deploy to deploy the stacks.
Once deployed, using the HostingUrl output value of CreateLeaveFrontendStack, you can access the frontend application to create a leave request.

SES by default in sandbox mode and only verified email addresses can receive emails. You need to raise a support ticket from your account to take it out of the sandbox mode so you can send emails to any address.
This is the first time I used CDK in a project and I am so much impressed how easy it is to deploy Serverless resources with it. This deserves a separate blog post :)
I have used few CDK modules which are still in alpha version (ex: aws-amplify-alpha). Those functionalities might be changed without prior notice.
Here, for demo purposes, Lambda function urls are not protected and can be triggered as public url. For a production system, those needs to be protected with AWS_IAM auth type.
To deploy the frontend in Amplify Web Hosting, locally built artifacts are used here. However, it is better to build this as part of a CI/CD pipeline where source code is fetched from Github.
For demo purposes, retry interval is set to 2 minutes. So, every 2 minutes the approver will get an email until leave request is processed.
Init Lambda function is only one from many other alternatives to trigger the step function (ex: event bridge rule).