In my previous blog post, I discussed the architecture decisions, CloudFormation setup, and security considerations for deploying a Spring Boot + React app on AWS.

Building on that foundation, this post will focus on creating a fully automated CI/CD pipeline which will automatically run tests and deploy the application every time code is pushed to GitHub.

Revisiting the Cloud Architecture

Recall that the cloud infrastructure for this application is deployed via CloudFormation. The backend is deployed to an EC2-backed ECS and the Frontend is deployed to S3 and served through CloudFront.

Creating the CI/CD pipeline

I decided to use GitHub Actions instead of AWS tools such as CodePipeline, because it’s both free and easy to use.

Before setting up the pipeline, I needed to address some security considerations and update the CloudFormation template to grant the necessary permissions to allow a successful deployment to AWS.

Security Considerations

A key security consideration was to use OIDC (OpenID Connect) instead of access keys for this deployment.

Malicious bots can automatically scan for the presence of AWS credentials in GitHub repositories resulting in account compromise, or malicious actors using your account to rack up tens of thousands of Euro. I didn’t have to wait long to see such an attempt on my server.

Note: a 200 response is returned because React handles routing client-side, the endpoint doesn’t exist on the server.

The fact that AWS access keys are long lived and don’t expire unless manually rotated poses security risks e.g. it requires storing the access key in GitHub Secrets and rotating it manually which is error prone and easy to neglect.

When using OIDC, GitHub generates a temporary token which AWS then verifies. This token allows GitHub to assume an IAM role temporarily which limits the scope and duration of AWS access. For this purpose, an GitHubActionsRole IAM role exists in AWS.

Adjusting the CloudFormation template for CI/CD

I started by amending my CloudFormation template to create a GitHub Actions IAM role that supports OIDC (OpenID Connect) authentication.

This role uses the sts:AssumeRoleWithWebIdentity action, which allows GitHub Actions to securely assume the role without requiring long lived AWS credentials. The trust policy ensures the request is coming from my GitHub repository for security reasons. I have omitted the code for this for brevity.

To support deployments to ECS, update the ECS service with new task definitions, upload frontend assets to S3, and trigger a CloudFront cache invalidation for fresh content delivery, I also created a custom policy named GitHubActionsDeployPolicy. This policy grants the necessary permissions for my deployment pipeline, as shown below.

        - PolicyName: GitHubActionsDeployPolicy
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Sid: AllowS3Actions
                Effect: Allow
                Action:
                  - s3:PutObject
                Resource:
                  - !GetAtt FrontendBucket.Arn
                  - !Sub "${FrontendBucket.Arn}/*"

              - Sid: AllowCloudFrontInvalidation
                Effect: Allow
                Action:
                  - cloudfront:CreateInvalidation
                Resource:
                  - !Sub "arn:aws:cloudfront::${AWS::AccountId}:distribution/${CloudFrontDistribution}"
              - Sid: AllowEcrLogin
                Effect: Allow
                Action:
                  - ecr:GetAuthorizationToken
                Resource: "*"

              - Sid: AllowEcsAndEcrDeployments
                Effect: Allow
                Action:
                  - ecs:UpdateService
                  - ecs:DescribeServices
                  - ecr:BatchCheckLayerAvailability
                  - ecr:InitiateLayerUpload
                  - ecr:UploadLayerPart
                  - ecr:CompleteLayerUpload
                  - ecr:PutImage
                Resource:
                  - !Sub "arn:aws:ecs:${AWS::Region}:${AWS::AccountId}:cluster/${ECSCluster}"
                  - !Sub "arn:aws:ecs:${AWS::Region}:${AWS::AccountId}:service/${ECSCluster}/*"
                  - !Sub "arn:aws:ecr:${AWS::Region}:${AWS::AccountId}:repository/taskapp"

GitHub Actions CI/CD

Using GitHub Actions, I created a CI/CD pipeline that is triggered when I push to my aws_deploy branch.

Notice below I divided this pipeline into several sections. This makes it easier to visualise what parts of the pipeline have succeeded or failed, allowing for easier debugging.

Building and Testing the Frontend

Building the frontend is very simple so I have omitted the code for brevity. It involves checking out the code, installing dependencies using npm ci and then building using npm run build

As I deploy the build in separate stage, I use the actions/upload-artifact@v4 action to make the build available in the deployment stage.

Deploying the Frontend

Deploying the frontend is relatively simple, I use OIDC to gain temporary credentials and assume the GitHub Actions Role, then use the frontend build which was generated in a prior stage and upload it to S3 and invalidate the CloudFront cache to ensure users see the latest version of my application.

  deploy-frontend:
    name: Deploy Frontend to AWS
    runs-on: ubuntu-latest
    needs: build-frontend
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Checkout
        uses: actions/checkout@v4.1.1

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::${{ secrets.AWS_ACCOUNT_ID }}:role/GitHub_Actions_Role
          aws-region: eu-west-1

      - name: Download frontend build
        uses: actions/download-artifact@v4
        with:
          name: frontend-dist
          path: frontend/dist

      - name: Upload build to S3
        run: |
          aws s3 cp frontend/dist s3://${{ secrets.AWS_S3_BUCKET }}/ --recursive

      - name: Invalidate CloudFront cache
        run: |
          aws cloudfront create-invalidation \
            --distribution-id ${{ secrets.CLOUDFRONT_DIST_ID }} \
            --paths "/*"

Building and Testing the Backend

This is quite straightforward. I use a ARM based runner as the EC2 instances I use are ARM based, checkout the code, set up the JDK and build the backend with Maven and finally run the backend tests using Maven.

  build-backend:
    name: Build & Test Backend
    runs-on: ubuntu-24.04-arm
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up JDK
        uses: actions/setup-java@v4
        with:
          distribution: 'temurin'
          java-version: '17'

      - name: Clean and Build Backend with Maven
        run: |
          cd backend
          mvn clean install -DskipTests

      - name: Run Tests with Maven
        run: |
          cd backend
          mvn test

Deploying the backend

To deploy the backend, GitHub Actions uses OIDC to gain the necessary temporary permissions. The backend Docker image is then built, tagged, and pushed to Amazon ECR (Elastic Container Registry). Finally the ECS Service is updated to ensure the latest version of the backend is fully deployed. Note that secrets such as AWS_ACCOUNT_ID are securely stored in GitHub Secrets.

  build-deploy-backend:
    name: Build & Deploy Backend to ECS
    runs-on: ubuntu-24.04-arm
    needs: build-backend
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::${{ secrets.AWS_ACCOUNT_ID }}:role/GitHub_Actions_Role
          aws-region: eu-west-1
 
      - name: Build Docker image (native ARM64)
        run: |
          docker build -t taskapp:latest ./backend
      - name: Login to Amazon ECR
        run: |
          aws ecr get-login-password --region eu-west-1 | docker login --username AWS --password-stdin ${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.eu-west-1.amazonaws.com

      - name: Tag and Push the Docker Image to ECR
        run: |
          docker tag taskapp:latest ${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.eu-west-1.amazonaws.com/taskapp:latest
          docker push ${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.eu-west-1.amazonaws.com/taskapp:latest

      - name: Update ECS Service
        run: |
          aws ecs update-service \
            --cluster ${{ secrets.ECS_CLUSTER_NAME }} \
            --service ${{ secrets.ECS_SERVICE_NAME }} \
            --force-new-deployment

Comparison of Docker Buildx vs native ARM 64 runner

Initially I was using Docker Buildx to cross compile for ARM since the EC2 instance has an ARM based architecture. This was very slow and resulted in the pipeline taking over 6 minutes to complete upon each push to GitHub.

As of January 2025, GitHub Actions now supports native ARM runners which reduced deployment time to roughly 2 minutes.

Lessons learnt

• Use OIDC instead of access keys for better security
• Use native GitHub Actions runner for faster deployments where possible

Conclusion

I really enjoyed learning how to build secure CI/CD pipelines to deploy applications to AWS. It allowed me to optimise my workflow as well as cut deployment time in half.

I wanted to gain experience with industry-standard AWS deployment practices, so I decided to rework the infrastructure behind my existing Task Manager app. The app itself which was built with a Spring Boot REST API backend and a React frontend remains unchanged. What’s different is how it’s deployed.

Previously, the app was deployed to Oracle Cloud using Docker Compose and a CI/CD pipeline. This time, I wanted to create an AWS-centric environment. A key constraint was to minimise the cost and as much as possible, stay within free tier limits.

Cloud Architecture

As illustrated in the diagram below, the user interacts with CloudFront, which intelligently routes requests for static content to an S3 bucket and API calls to the Application Load Balancer (ALB). Note the VPC and Internet Gateway are omitted here for brevity.

Design Decisions

Backend

Lambda vs ECS-EC2 vs Fargate

AWS Lambda (Serverless)

• Fully managed, scales automatically with demand
• Cold starts can be significant for Java applications like Spring Boot

ECS with EC2 Launch Type

• Full control over EC2 instance
• Can use a free tier EC2 instance to minimise costs
• Requires manual management of instance lifecycle and scaling policies

Amazon ECS with Fargate

• No need to manage EC2 instances
• Seamless scaling
• Does not appear to be free tier eligible

Decision: I chose ECS (EC2) as it offers a balance between cost, flexibility, and suitability for a containerised Spring Boot app. It allows me to stay within the AWS Free Tier while still simulating a production-like environment. ECS also provides container orchestration capabilities such as service discovery, load balancing, health checks, and auto-recovery of failed containers.

Database

I chose Amazon RDS with MySQL to meet the application’s original requirements without modifying the codebase.

Why RDS?

• Managed database which has many benefits such as automated backups, patching, and scaling
• Simplifies setup and management compared to self-hosted alternatives
• Can stay within Free Tier limits if you use a db.t3.micro instance

Why not self-hosted MySQL in ECS?

• Adds unnecessary operational overhead (no managed backups, scaling or failure recovery)
• Increase complexity without offering substantial benefits for this project

Application Load Balancer (ALB)

While the primary role of a load balancer is to distribute incoming traffic, AWS Application Load Balancer (ALB) offers additional benefits such as:

• Health Checks: ALB provides robust health checks at the application layer, allowing it to monitor the actual responsiveness of the application endpoint. This ensures that traffic is only sent to truly healthy instances, improving application availability

• No longer need to worry about EC2 instance IPs changing (e.g. on restart) as we are using the public DNS of the ALB

It’s worth noting that while I limited the number of instances to reduce costs, the setup can be easily scaled to increase availability and performance if needed.

Networking:

Using a NAT Gateway in eu-west-1 would cost ~$34.56/month + data charges which is far too expensive for a proof-of-concept. Instead, I used a NAT instance to keep the costs down.

It’s worth noting that while a NAT Gateway is fully managed and more scalable, using a NAT instance can be significantly cheaper even after accounting for the cost of an extra EC2 instance (since NAT functionality requires one instance to act as the NAT).

Although this setup would normally exceed the AWS Free Tier limit, I was able to offset this charge entirely as AWS approved my $300 free credits application.

As the ECS (EC2) backend is inside a private subnet in order to prevent direct internet access to it for security reasons, the NAT instance is needed to pull Docker images from ECR (Elastic Container Registry).

Frontend

The main choices for the frontend was to either deploy it in ECS-EC2 like the backend or instead use S3 + CloudFront. The latter was the obvious choice as it has the benefits of:

• DDOS protection
• Decoupling of frontend and backend logic
• TLS support through ACM (AWS Certificate Manager)
• Use of a CDN to cache content in edge locations while remaining a low cost option (effectively free) for a low traffic application such as mine.

ECS-EC2, on the other hand, would have introduced additional operational overhead with no clear benefits especially since I wasn’t using server-side rendering (SSR).

Deployment

As mentioned previously, one of my goals was to be able to deploy this app without having to modify the existing code base. A key enabler of this was the use of an Infrastructure as Code (IAC) approach which allows the provisioning IT infrastructure through code, rather through graphical interfaces. This code becomes a version-controlled, repeatable template that can be deployed multiple times in different environments.

I chose to use CloudFormation for my IAC. Which provides the following benefits:

• The application’s underlying code doesn’t have to know it’s using AWS, avoiding vendor lock in

• The application code does not need to call the AWS SDK to fetch secrets (e.g. db password). ECS injects them, which again keeps the app portable

• Can roll back changes in case of failure

• Reproducible deployments

Here we fetch the secrets from Secrets Manager in the ECSTaskDefinition, avoiding hard-coding sensitive information in the template.

Environment:
- Name: SPRING_DATASOURCE_USERNAME
  Value: !Sub "{{resolve:secretsmanager:/taskapp/db-credentials:SecretString:username}}"
- Name: SPRING_DATASOURCE_PASSWORD
  Value: !Sub "{{resolve:secretsmanager:/taskapp/db-credentials:SecretString:password}}"
- Name: JWT_SECRET
  Value: !Sub "{{resolve:secretsmanager:/taskapp/db-credentials:SecretString:jwt}}"

As I am using a t4g.small instance for my EC2 backed ECS which runs on ARM it was necessary to cross compile the docker image for the backend to ARM64 before pushing the image to ECR (Elastic Container Registry), so it could run on the instance. ECR is essentially just a private Docker image repository.

Given the full template is over 600 lines, here’s a concise summary of the main components:

• Networking: Sets up a VPC with public and private subnets across two Availability Zones, an Internet Gateway, and route tables. It also includes a NAT instance (as an alternative to a NAT Gateway) to allow private subnets to access the internet

• Security Groups and IAM roles: More on this later

• ECS Task Definition and Service: Defines an ECS task definition for the taskapp-container using a Docker image from ECR, An ECS service is created to run and maintain the desired count of tasks on the ECS cluster, integrating with the ALB.

• ECSLogGroup: Contains CloudWatch logs from the SpringBoot backend, helpful for debugging

• ALB: Creates an Application Load Balancer (ALB), a target group for the ECS service, and an ALB listener to forward HTTP traffic to the ECS tasks.

• RDS (MySQL): Database: Provisions a MySQL RDS instance

• S3 + CloudFront for React Frontend: Sets up an S3 bucket to host the static React frontend, along with a bucket policy to allow CloudFront access

• Outputs: Outputs the CloudFront URL for the frontend, can be used as the CNAME target when configuring a custom subdomain (e.g., app.example.com).

One challenge when using CloudFormation at first was that if the stack failed to create, it would delete the logs making troubleshooting difficult, but there is an option to retain the logs even after stack deletion.

Security Considerations

As much as possible, I tried to adhere to AWS security best practices for my deployment.

Secrets Manager

• Extremely important to not hardcode sensitive secrets in CloudFormation, there have been cases of compromised secrets through this, leading to AWS bills in the 10’s of thousands!
• Database secrets and JWT token are encrypted by AES-256 and fetched from the SecretsManager

Session Manager vs Instance Connect

• AWS recommends using Session Manager instead of Instance Connect as it allows the SSH port to be closed, reducing the attack surface

CloudFront

• Provides DDOS protection by default
• ViewerProtocolPolicy: redirect-to-https forces secure access
• Security Headers set to the AWS managed security policy (e.g. provides HSTS and X-Frame-Options headers)
• S3 access control: Origin Access Control (OAC) ensures only CloudFront can access the S3 bucket

  FrontendBucketPolicy:
    Type: AWS::S3::BucketPolicy
    Properties:
      Bucket: !Ref FrontendBucket
      PolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: cloudfront.amazonaws.com
            Action: s3:GetObject
            Resource: !Sub 'arn:aws:s3:::${FrontendBucket}/*'
            Condition:
              StringEquals:
                AWS:SourceArn: !Sub "arn:aws:cloudfront::${AWS::AccountId}:distribution/${CloudFrontDistribution}"

  CloudFrontOAC:
    Type: AWS::CloudFront::OriginAccessControl
    Properties:
      OriginAccessControlConfig:
        Name: !Sub '${AWS::StackName}-FrontendOAC'
        SigningBehavior: always
        SigningProtocol: sigv4
        OriginAccessControlOriginType: s3

Note in the ARN, the CloudFront distribution created elsewhere in the template is referenced as the condition, this ensures that only that specific CloudFront distribution is allowed to access the S3 bucket.

RDS

• The database is not publicly accessible, reducing the attack surface
• RDSToECSTaskIngressRule: Allows TCP 3306 from ECSTaskSecurityGroup. Restricts database access solely to the ECS tasks that need to connect to it
• RDS in contained within a private subnet
• Secrets obtained from Secrets Manager

VPC & Networking: Provides a dedicated, isolated network

Security Token Service (STS)

• STS: AssumeRole provides temporary credentials eliminating the need to store access keys in code. This eliminates the risk of credentials accidentally being exposed (e.g., in Git repos or logs)
• AssumeRolePolicyDocument defines who can assume the role

  ECSInstanceRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              Service: ec2.amazonaws.com
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role
        - arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
        - arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
        - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore

AWS Certificate Manager (ACM)

• TLS certificate generated in ACM through DNS validation
• ACM can auto-renew the certificate
• The certificate can be attached to CloudFront, enabling HTTPS for the frontend with a custom domain

Lessons learnt

• Use correct AMI (e.g. using old AMIs could introduce security flaws)
• Be careful to research the cost of using each service
• Setup billing alarms to keep an eye on costs incurred
• Avoid CloudFormation stack rollback on failure: Enable log retention and manual deletion for better debugging
• Use the DependsOn attribute in CloudFormation to ensure resources in the stack are created in the right order
• Debugging Tip: At times CloudFormation can appear to hang. I found it helpful to get Early Error Detection by checking the ECS Task Status, CloudWatch and Health Checks status
• Certificate for CloudFront must be created in us-east-1 region

Future Enhancements

• Add a CI/CD pipeline to upload frontend code to S3 to invalidate the cache and upload backend to ECR
• In a production environment with real users, enable CloudTrail and GuardDuty for increased security (cost involved)
• If cost wasn’t an issue, use NAT Gateway instead of a NAT instance
• Could use the Cloud Development Kit (CDK) to create the CloudFormation template

Conclusion

I really enjoyed completing this project and deepening my understanding of AWS infrastructure. It gave me hands-on experience with IaC, container orchestration, and secure cloud deployment

Chingu is an online platform that brings together Scrum Masters and developers from around the world to participate in a collaborative six-week voyage (project). During this time, teams work together to deliver an app, all while adhering to Scrum principles.
Our recent project was the creation of an AI prompt app, from the initial concept to a deployed app at the end.

Starting the Voyage

We were a team of seven, consisting of five developers, a Scrum Master, and a Shadow Scrum Master.
To kick off our voyage, we began brainstorming ideas for a project we could complete within six weeks. After discussing various options, we decided to create an AI Prompt App that integrates with the Google Gemini API.
This app features a pentagram-style form, allowing users to create and submit custom queries to the AI model by filling in five key components:

• Persona: Defines the role or identity of the AI for context.
• Context: Describes the background or scenario in which the AI should operate.
• Task: Specifies the task or action the AI should perform.
• Output: Details the desired outcome or format for the AI’s response.
• Constraint: Sets any limitations or boundaries for the AI’s response.

With a clear concept in place, we moved on to defining a simple yet functional Minimum Viable Product (MVP). Estimating development time at this stage was challenging, so we kept the scope minimal and allocated a week for bug fixes. To stay user-focused, one team member created a Figma flow illustrating the app’s pages and how they should behave based on user login status, which was then reviewed and refined by the team.

From this, the Scrum Masters created a Jira board with a backlog of all tasks to be completed for our MVP (and some stretch goals). We agreed on a tech stack (see below), and agreed on some ground rules (such as daily standups, a GitHub workflow etc.).

Tech Stack

• Backend: NodeJS, Express, TypeScript
• Frontend: React, Tailwind CSS, TypeScript
• Database: PostgreSQL (hosted on Supabase)
• Deployment & Hosting: Nginx, Render, Netlify
• Collaboration: Jira
• Prototyping: Figma

Development Experience

As mentioned above, we were a team of seven, all from different backgrounds and all bringing different skills / perspectives to the voyage.

We decided on a 3 meetings a week approach (with daily standups in between), in theory, we’d have one day to introduce the sprint (with each sprint being 5 days long), add items from the backlog to the sprint and assign developers to those tasks. Then, we would have a meeting mid-week to discuss any challenges that came up and then finally on a Friday, one quick meeting to close off the sprint and hold a sprint retrospective.

At times, it was helpful for team members to divide into unofficial “sub-groups” to work collaboratively on a feature. When this happened, it allowed bugs to be addressed early as well as improving the coding practices early on.

On the technical side of things, it was my first time using NodeJS + Express + TypeScript as well as PostgreSQL. While NodeJS + Express was a bit of learning curve for me, I enjoyed using them. On the other hand, I found PostgreSQL quite easy as I was already familiar with MySQL, and TypeScript was reasonably straightforward.
We created a REST API for the frontend to communicate with the backend and vice versa and secured the endpoints with JWT based authentication.

At the end of the voyage, I am proud to say that we collectively achieved our MVP and deployed the fully working application to the web.

Git Best Practices

We strove to adhere to Git best practices in this voyage. Our workflow consisted of feature branches, hotfix branches, a development branch and a main branch.
We disallowed direct pushes to the development or main branch in order to isolate any bugs that occurred in the feature branch where they occurred. When a developer was satisfied their feature was complete, they created a Pull Request (PR) to merge their feature branch into the development branch, which another developer would have to approve (or request changes) before merging the changes. Similarly, at the end of a sprint a PR would be created to merge the development branch into the main branch.

Testing

Given the time constraints, testing on this project was limited to validating API responses using Postman and having developers manually test each other’s PRs.

If we had more time, I would have liked to add automated tests using Jest and SuperTest to ensure the API endpoints returned the expected responses. Additionally, I would have liked to set up continuous integration using GitHub Actions to automatically run these tests on every push to the repository

Documentation

We used Swagger to document the REST API endpoints. This will make it easier to maintain the app in the future and help any new developers quickly understand how the API works.

Deployment

For deployment, the goal was to have a completely free deployment that didn’t require a credit card. We decided on Netlify + Render.

Render has “cold-starts” whereby the user may experience a delay if the app hasn’t been used recently. This is a limitation of the free tier but it was a tradeoff we were willing to accept as this app is mainly a proof of concept.

One of the challenges was coming up with a hosted database that didn’t have any excessive restrictions (e.g. Render automatically deletes the database 30 days after creation if you use the free tier.)
In the interests of saving time, we decided to initially use a local PostgreSQL database while we researched what hosted database to use, knowing that when we eventually decided on what hosted DB to use, the code changes would be minimal.

Eventually, we decided on a Supabase hosted DB, which was very easy to set up.

Deployed App

Press here to access the AskIQ App

Lessons Learnt

• Importance of daily standups / communication so issues can be addressed quickly and “head-on”

• Avoiding “scope change” (e.g. don’t deviate from the MVP at late stages during a sprint)

• Keeping meetings action based and focus on achieving the MVP

• Avoid overcomplicatating the organisational side of the project (e.g. for this small project, Trello might have been simpler than Jira)

Future Enhancements

• Allow users to save personas and load them subsequently

• Add rate limits to the app

• Add unit and integration testing

• Minimise the “cold-starts” on Render

Conclusion

Working on this project with the team was an excellent opportunity to gain experience in a simulated software development environment.
We aimed to mimic a real-world software project by following Scrum principles and maintaining a solid GitHub workflow. Although we faced challenges along the way, we were able to deliver our MVP, deploying the completed app to the web.

If you’d like to dive deeper into the code or explore the project further, here’s the Github Repo

I wanted to build a full-stack application to get hands-on experience with SpringBoot, React and REST APIs. Additionally, I wanted to take a concept from the planning stage all the way to deployment.

Programming languages / Frameworks / Tools used

• Backend: Java, SpringBoot, REST API
• Frontend: React + Tailwind CSS
• Database: MySQL
• Containerisation: Docker
• Deployment & Hosting: GitHub Actions, Nginx, Oracle Cloud
• Automated Testing: JUnit and Mockito

Development Experience & Challenges

Building this task management application introduced me to a variety of new challenges and learning opportunities.

On the backend, one of the biggest hurdles was working with Spring Security. I quickly discovered that Spring Security keeps rapidly evolving, with deprecations and removal of methods between versions and the documentation isn’t always up-to-date or easy to follow. That said, Spring Security was still useful as it allowed me to implement robust authentication and authorisation mechanisms.

I chose Hibernate as the ORM to handle database interactions. I was pleasantly surprised by how powerful and easy it was to integrate with Spring Boot, allowing for smooth CRUD operations without writing SQL queries manually.
I decided to use MySQL for the database, since each user has their own list of tasks, a relational database was an obvious choice for this application.

For handling authentication, I used JWT tokens. This allowed me to implement stateless authentication, where every user is assigned a JWT token upon logging in which is set to expire after a set time period.

On the frontend side, this was my first time working with React, and I found state management to be a challenge initially but overall, I enjoyed using React and found the documentation to be helpful.
React’s single-page approach is different from traditional server-side frameworks like Flask and Thymeleaf that I would have been more familar with conceptually. Traditionally with frameworks like Flask, the server handles rendering most of the content, whereas in a React SPA, the frontend is responsible for much more of the user interaction and rendering.

I used Tailwind CSS to create a responsive design for the webpages, which I hadn’t used previously, but I found it very easy to use.

Modern browsers have a security feature known as the Same-Origin Policy (SOP), which prohibits a site’s JavaScript to make requests to another destination than the site itself.
As my backend and frontend are hosted on different domains, I had to configure CORS in the backend to allow the frontend to communicate to the backend without being blocked by the browsers SOP.

So, the backend and frontend are running on different domains (and ports), how does the frontend talk to the backend? The answer is through a REST API.

Testing

I used JUnit and Mockito for both unit and integration testing in the backend. Unit tests helped validate the behaviour of individual methods, while integration tests were used to verify interactions between different layers of the application (e.g., service and repository layers). With Mockito, I was able to mock dependencies to isolate and test logic without relying on actual implementations.

Deployment

Unexpectedly, one of the biggest lessons I learnt from doing this project was learning how to deploy it!
I decided to use Docker to containerise my application for easy deployment, but when I tried to deploy my docker images onto the VPS running on Oracle Cloud, I ran into issues because the free tier VPS was running on a ARM64 architecture but the docker images had been built for a X86 architecture as that was what my own machine was using. So, I cross-compiled to ARM64 and was able to successfully deploy the application to the web.

However, this process was quite tedious to have to repeat every time I wanted to make a change to the application, so I decided to implement a CI/CD pipeline using GitHub Actions. This allowed the docker images to automatically be updated and cross-compiled using Docker buildx to both X86 and ARM_64 after I pushed any new code to GitHub.
Another benefit was that my unit and integration tests would also be automatically executed after each push to GitHub and if the tests failed, the docker images would not be updated in order to avoid pushing buggy code to production.

Finally, I used a reverse proxy to proxy the API requests to the backend container running on Docker and used Let’s Encrypt to generate a TLS certificate for the deployed website.

Deployed App

Click here to visit the deployed app

Future Enhancements.

• Add OAuth integration
• Refresh the JWT tokens upon expiry.
• Add notifications for due tasks

Conclusion

I really enjoyed completing this project, from the initial scoping stage to having a deployed web-app at the end.
Through the challenges I faced, I was able to learn more about React state management, CI/CD pipelines and Docker.

If you’d like to dive deeper into the code or explore the project further, here’s the GitHub Repo