Cloud Native Fundamental Project 1 - March 2021
Table of Contents:
- Tuition Scheduler App
External Resources:
The goal of this project was to create a CRUD application using a variety of tools, methodologies, and technologies that were covered during training.
Below is a set of high-level requirements to be fulfilled for the successful completion of this project:
- Complete a Jira board with user stories, use cases and tasks.
- Write documentation describing the architecture used.
- Create a detailed Risk Assessment for the project.
- Create a SQL relational database used to store data persistently for the project.
- Create a Persistence API in Java that meets the requirements set on Jira.
- Using HTML, CSS and JavaScript, create a functioning front-end website and integrate API.
- Design automated tests for validation of the application using JUnit and Mockito for unit and integration testing.
- Deploy the MySQL database onto a GCP instance.
- Integrate the code fully into the version control system, Git.
A tuition scheduler web app created for teachers/tutors to maintain their students' details. It allows the user to create, read, update, and delete student entries from a database.
- When the user opens the webpage to the homepage, they can see a list of students currently stored in the database with their first name, last name, and student ID displayed in a card layout.
- When a card is clicked all the student's information (age, parent's name and contact number) is displayed as a modal popup, along with options to edit the contact number, delete the student entirely, or close the modal.
- To update the contact number, the user would click on the edit button. Upon clicking the edit button, an input box would appear where the user can enter the new contact number, along with a save button where the user can save this to the database through the API.
- There are checks happening in the front end when the user enters the details in the input forms, so for example, when a contact number that is entered is too long, an error message will appear.
- There is also a clear button to add a new student that will allow the user to create a new student entry in the database through the API. Upon clicking submit, the regex checks would occur and display the error field to the user if there are any errors. If not, a put request is sent, then the page is refreshed showing the new card at the bottom of the stack.
Project planning was done in Jira. The Tuition Scheduler web app initiative was split into 3 main epics that were then broken down into multiple user stories. The user stories are features of the project written from the user's perspective in the form of 'As a..., I want to..., so that...' An example of a user stories that was written up for this is:
- As a user, I want to add new students to the app, so that I can enrol new students when they join.
The user stores were then given story points based on the relative effort it took to complete them, along with the subtasks for each user story. The example user story and its subtasks can be seen on Jira below:
The user stories were then put into respective sprints and a kanban board was used to track progress. Below is the Development and Testing Sprint Kanban board as the project was nearing completion:
The completed user stories and the current backlog can be accessed on Jira here.
Below is the risk assessment that was conducted for the project:
Risk Assessment on Google Drive.
This app utilises Spring Boot's multi-layered architecture in which there are 4 layers:
- Presentation Layer - Front-end layer responsible for taking JSON inputs and performing a representation state transfer from JSON to plain-old-java-objects, and displaying errors if user inputs do not adhere to specified formats.
- Business Layer - Handles the business logic of the application.
- Persistence Layer - Contains database queries allowing translation from Java objects to database rows.
- Database Layer - Contains the MySQL database. CRUD is performed in this area. The database layer is hosted on a GCP instance.
The diagram below shows the interactions between the 4 layers for this specific app with technologies used at each stage.
An entity relationship diagram of a database shows the relationships between the tables in the database. It was created early on in the project to get an understanding of the structure of the web app. The MySQL database has been hosted on Google Cloud Platform. Currently, only one table has been implemented - the student table. The ERD below shows the plans to expand the database.
This UML diagram describes the structure of the API.
A user flow diagram is a flow chart that shows the journey the user can take through the app. Having a user flow diagram was very useful when coding the front-end, as it gave a clear idea of the options a user has when navigating through the app.
Testing is the process of checking for bugs in code. It is vital because if any changes happen to the code base, you would have to run the test to check that any code-breaking changes weren't made.
Testing was conducted using the unit testing framework, JUnit, and Mockito to isolate the behaviour of an object by creating a 'mock' object to ensure the real dependencies are not used.
A 'Given', 'When', 'Then' approach was taken. A set of Java objects were converted to JSON and were used as inputs into the test to simulate the front-end. The JSON objects were sent through the API creating a table row in the database, which was then received and compared against the simulated data for a match. The 'verify' method was used to ensure the method that is being tested had been called.
In this project, testing is automatically conducted as one of the steps Maven build lifecycle. More about the build lifecycle in the Deployment section.
The screenshot below shows the results for all the tests, with all the methods tested resulting in an 88% coverage.
Front end technologies that were used included, JavaScript, HTML 5 CSS, and Bootstrap 5. The webpage is currently hosted on GitHub pages.
When the user opens the webpage the front-end sends a GET request to the API. The user is presented with a list of all the students currently in the database in the form of clickable bootstrap cards.
There is a card that will allow users to enroll new students. Upon clicking on it, the user would be presented with a modal with a form where the user can enter the information.
If the user enters the details incorrectly (for example, the user enters an age greater than 100), or leaves the field empty, they are presented with an error at the bottom of the modal.
Once the user clicks submit, the front-end converts the user inputs into JSON format and sends a POST request to the API. The page is refreshed so that the front-end can send another GET request, letting the user see the new student at the bottom of the card stack.
When the user clicks on one of the cards, they are presented with the modal that shows all the information of that student that is on the database, along with options to edit the contact number or delete the student from the database by sending a DELETE request to the API.
If the user decides to edit the contact number, they are shown a field where they can enter the new contact number. A similar check of the input is done when the user enters an invalid number (letters in the phone number field). When the user saves, a PUT request is sent to the API and the page refreshes, showing the updated contact number when the card is clicked.
To build the app, open up the terminal/command prompt and navigate to the root folder of the web app and issue the command mvn package This is a maven phase, so running this command will execute and run validate compile, test and package, to finally generate a .jar file.
The output of this, when run in terminal, can be seen below. All tests have passed and the .jar file has been built successfully
A CI pipeline can be implemented but has not for this project as of yet.
Once a GCP instance for MySQL Database has been created, the user can run mvn spring-boot:run to run the API on the localhost and open the site on GitHub pages to use the app.
One of the problems with this app is that although the front-end and the database are deployed, the API is running on localhost. This means that if someone would want to use this app, they would need to keep the API running on their computer. This problem could be solved by hosting the .jar file onto GCP's App Engine instance, but this is something that this project has not covered.
With regards to the front-end, I would like to implement an authentication system, which would allow multiple users to access their own set of students in their own database. This login feature is vital to maintaining personal information secure.
The current ERD shows the other tables in the database and functionality that has yet to be implemented in the front-end (courses manager, lesson planner). This is due to the time constraints of this project.
In the back-end, there are methods in the controller that can perform a 'read by student ID', and a 'find by student name'. These methods can be used to implement a search feature on the front-end in the future.
When editing the contact number, the user is not able to change any of the other information (like first name, last name) about the student without first deleting the student and creating a new one with the updated information.
Once the fetch method is run to put or post information to the API, the whole webpage has to be refreshed to present the new data.
This project is licenced under the MIT licence.
Tuition Scheduler Version 1 Author: Manish Reddy
I would like to acknowledge:
- The trainers at QA for giving me the skills for the successful completion of this project.
- My peers at QA for support and entertainment during this project.
- My mum for giving me the idea for this app.