There are approximately 6,800 courses at the University of Auckland. These courses are organized into around 250 studies, which are further grouped into 9 faculties (including General Education).

🛠️ 2. Database Design Choices

When designing the database, I considered a few options. One was to create three separate tables — Faculty, Study, and Course — and perform joins when querying, for example, the list of studies under a specific faculty. The other option was to consolidate all information into a single table with 6,800 rows.

I chose to create a single, denormalized table for the following reasons:

1. Courses rarely change, and the system would experience very few write or delete operations. In other words, the table can be treated as a static dataset with primarily read operations, making a single table sufficient.
2. 6,800 rows is relatively small and does not warrant normalization purely for size reasons. Querying such a table typically takes around 150ms, which is fast enough that it would not negatively impact user experience (UX).

Therefore, considering both the low update frequency and the acceptable query performance, I determined that a simple, denormalized design would be the most efficient and practical choice for this case.

Engineering Faculty Page — Listing Studies

Accounting Study Page (Business Faculty) — Listing Courses

🎯 3. UX Challenges and Improvements

Initially, I designed three separate pages: a Faculty page, a Study page, and a Course page. However, navigating to course reviews required too many steps: Faculty page → click → Study page → click → Course page → click → finally see the reviews.

To improve the user experience (UX), I replaced the Faculty page with a faculty navigation bar that allowed users to jump directly to their desired faculty. This reduced user’s click and made navigation much more intuitive.

🐢 4. Performance Bottleneck: Initial Observations

However, I noticed another issue: loading studies and courses felt slow. It wasn’t that it took longer than a second to load, but it still wasn’t as smooth and immediate as I wanted.

Upon reviewing my code, I initially suspected that alphabetical sorting might be a bottleneck. But after analyzing the complexity, I realized that sorting a maximum of 80 courses would only involve approximately O(n log n) = 504 comparisons — a trivial amount of work for a modern CPU, likely completing within just a few milliseconds.

After further research, I discovered Redis.

🚀 5. Implementing Redis for Caching

Redis is an in-memory, NoSQL key-value store, which was exactly what I needed.

Being ` NoSQL-based means Redis stores data in flexible key-value structures, making it **highly accessible** and **intuitive** for my use case. Furthermore, its schema-less` nature perfectly matches the structure of courses and studies, which do not require rigid relational models.

From a performance perspective, Redis is optimized for speed: all data is kept directly in RAM rather than on disk. This allows data retrieval times to skyrocket — accessing RAM is thousands of times faster than disk I/O. Redis can easily handle hundreds of thousands of requests per second, making it an ideal solution for reducing latency and delivering a much smoother user experience.

🎉 6. Conclusion

I implemented caching for studies and courses using Redis, which significantly improved data retrieval speed compared to direct database queries. As a result, users experienced minimal loading times when navigating the frontend, and overall, the application’s responsiveness and user experience were greatly enhanced. Although there is still a slight delay, it has been reduced considerably. Beyond the performance improvements, I am also glad that I discovered Redis and its many powerful features through this process.

I made a significant change to my original plan. Initially, I intended to use only JWT (Bearer Token)–based authentication for all users. However, I decided to integrate Google OAuth authentication to allow users to sign in without storing their credentials on the Quad server.

This decision was made with user trust in mind. I realized that some students might be hesitant to register due to concerns about the security of the Quad server. By using OAuth, users can authenticate via Google, ensuring that their credentials are never directly handled or stored by our backend.

I did not implement a “Sign Up with Google” button on the registration page. Instead, I separated the flow into two distinct endpoints:

1. First-time Google OAuth users: After successfully authenticating via Google, users are redirected to a page where they must set a unique username to complete their account setup.
2. Returning Google OAuth users: If the user has previously signed up using Google OAuth, they are redirected directly to the main page, and a cookie containing the JWT is set on the client side for session management.

🚏 Api Endpoints for Sign-up and Sign-in

To implement complete authentication logic (including OAuth support and email verification), I have created the following server-side API endpoints:

1. Post /api/v1/auth/sign-in

2. Post /api/v1/auth/sign-up

3. Post /api/v1/auth/email-verification

   ​ : Sends a verification code to the provided email address.

4. Post /api/v1/auth/confirm-email-verification

   ​ : Validates the verification code submitted by the user.

5. Post /api/v1/auth/username-check

   ​ : Checks whether the desired username is already in use.

6. Patch /api/v1/auth/change-username

   ​ : Updates a user’s username. This is only used for users who sign up via OAuth, as they are initially assigned a default username. This endpoint allows them to set a custom, unique username.

🎰 Email verification code

I recently purchased the domain quadnz.com to set up a custom enterprise Google email for my project. As part of the user sign-up process, I needed an email address to send verification codes. I decided to use the standard naming convention and created:

no-reply@quadnz.com

🏠 Sign-up and Sign-in pages

Sign-up and Sign-in is implemented with 4 pages.

As users enter input or verification codes, buttons gradually light up to guide their actions. Blue text indicates success, while red text is used for error messages.

When a user signs in with Google (OAuth) for the first time, they are redirected to a page where they need to set their username. Technically, they already have a default username assigned during sign-up, so this step is actually about changing the default username to a custom one.

Conclusion

This time I worked hard to implement Google OAuth, and honestly—it was a lot of fun. Seeing my site evolve and finally start to feel like a “proper website” was incredibly satisfying.

Moreover, implementing sign-up and sign-in also gave me a chance to think more deeply about user experience (UX). I put a lot of effort into making the sign-up flow feel smooth and intuitive. I didn’t want users to get bored or confused and leave halfway through the process. That’s why I designed the buttons to gradually light up as users interact with the form.

Next up: I’ll be working on the main page. There’s a lot more to do there. I’m planning to build a header, a sidebar, a trending reviews , recent reviews, and possibly even a review chart to visualize some data.

Before implementing user sign-in and sign-up, we need to decide on an authentication method. Generally, there are three common authentication approaches:

1. Basic authentication: This method involves sending the user’s credentials (user ID and password) encoded in Base64 with every request. While it is simple to implement, several critical issues make it unsuitable:

   1. Insecure: Basic authentication transmits credentials in an encoded format, not encrypted. Encoding is reversible, meaning attackers can easily decode and retrieve user credentials.
   2. Lack of session management: Since there is no session or token-based authentication, users must send their credentials with every request. This results in a poor user experience😡, as users have to repeatedly enter their credentials for every interaction, such as liking or commenting.

2. OAuth Authentication: Many of you have likely signed up for a website using third-party providers such as Google or GitHub. This process is implemented using OAuth authentication. OAuth allows users to sign in using external identity providers (e.g., Google, GitHub) without directly handling their credentials.

   However, I have decided not to use OAuth for Quad because I will not be integrating third-party authentication services. Although OAuth can also support internal authentication systems, implementing it requires significantly more time and effort compared to the next authentication method I will introduce.

3. Bearer Token: When a client signs in, the server generates and transmits a Bearer Token to the client. This token remains valid until its expiration time set within the token.

   Once the client receives the Bearer Token, it can use it for authentication by attaching it to the HTTP request header when accessing protected resources. This is a example of an HTTP request header with a Bearer Token:

   Authorization: Bearer <token>
   

   I will implement Bearer Token authentication using JWT (JSON Web Token), which provides secure and stateless authentication. It ensures security through encryption with specific algorithms, and its stateless nature eliminates the need for servers to store session data. This means the server doesn’t need to query the database for each request, resulting in faster and more efficient authentication.

JWT…? Who are you?

1. How is a JWT token structured?

   Jwt is consist of three parts, separated by dots(.):

   <Header>.<Payload>.<Signature>
   

   eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyQGV4YW1wbGUuY29tIiwicm9sZSI6ImFkbWluIiwiZXhwIjoxNzEwOTUwNDAwfQ.H0VlMa2UNxIl_6Im7vx2gCy0j2sr_vsaKdmX9EoIqKw
   ### This is what a JWT looks like.
   ### Try to find the two dots separating the JWT sections!
   

   1. Header: This section defines the signing algorithm. I chose a symmetric key algorithm because it’s simpler to implement than asymmetric key algorithms. 😂
   2. Payload: It contains data fields, such as user data and JWT expiration time. ✅ Every payload properties are called claims.
   3. Signature: The signature is generated when the JWT is created. It is formed by encrypting the header and payload using the server’s secret key. Once created, the signature cannot be altered.

2. How is JWT used for authentication?

   

   1. The client signs in with a username and password and sends an HTTP request to the server for authentication.
   2. The server verifies whether the provided credentials are valid by checking them against the database.
   3. If valid, the server generates a JWT, and sends it to the client in an HTTP response as aJSON object.
   4. Once the client stores the JWT, it is used as a Bearer Token for authentication.
   5. For future requests, the client includes the Bearer Token in the HTTP headers until the JWT expires.
   6. When the client sends a request with the Bearer Token, the server verifies the JWT. If the token is valid and not expired, the server processes the request; otherwise, it rejects it.

In which part of the application is the Bearer token validated?

In Spring Boot, when a client sends a request, it passes through several filters before reaching the controller. Filters act as a security layer, verifying whether the request is valid.

Generally the request first goes through

1. CORS filter

2. Spring Security filter

3. Custom filters like JwtAuthenticationFilter

4. And finally reaches the DispatcherSevlet which maps HTTP request to appropriate controller.

1. CORS filter

   To understand CORS(Cross-Origin Resource Sharing), we need to understand SOP(Same-Origin Policy). SOP is a fundamental security mechanism enforced by web browsers that restricts web pages from making requests to a different origin (protocol, domain, or port) than the one that served them. Origin refers to the protocol, hostname and port of a web application. Here is a example of origin:

   <protocol>://<hostname>:<port>
   ## e.g. http://localhost:3000
   

   By default, SOP prevents unauthorized cross-origin requests, protecting data from malicious websites. For example, a front-end application running on http://localhost:3000 cannot directly access an API hosted at http://localhost:8080 due to SOP restrictions.

   To enable cross-origin communication, the backend server must explicitly allow the frontend domain using CORS (Cross-Origin Resource Sharing).

   To allow a frontend (http://localhost:3000) to send requests to the backend, configuring CORS in the backend is required.

   CorsConfiguration configuration = new CorsConfiguration();
           configuration.addAllowedOrigin("http://localhost:3000");
   

2. Spring Security filter

   Spring security applies security logics such as authentication (who you are), authorization (what can you access) and CSRF (Cross-Site Request Forgery) protection.

   In WebSecurityConfig.java, the security configuration file, there’s an interesting point to highlight.

   httpSecurity.csrf(CsrfConfigurer::disable)
   

   I have explicitly disabled CSRF. Even for someone unfamiliar with CSRF, just reading the term might give the impression that disabling it is a bad idea. So why have I disabled it?

   CSRF (Cross-Site Request Forgery) is an attack where a malicious website tricks an authenticated user into making unwanted requests to a web application while they are logged in. Being logged in means that the user is authenticated and has an active session on the server, rather than using stateless token-based authentication like JWT. In other words, it can be safely disabled when using JWT or Bearer Tokens.

3. JwtAuthenticationFilter

   JwtAuthenticationFilter is a custom Spring Security filter that extracts the JWT from the Authorization header, and validates it using JwtProvider. If the token is valid, it extracts the user details and stores them in SecurityContextHolder, making the user data accessible throughout the application.

   SecurityContext securityContext = SecurityContextHolder.createEmptyContext();
   securityContext.setAuthentication(authenticationToken);
      
   SecurityContextHolder.setContext(securityContext);
   

Getting Started

Therefore, I decided to create a website where UOA students can write lecture reviews and give ratings. This will allow students to enroll in the paper that best fits their needs. I was not able to find any front-end developer, but I guess this could be the perfect opportunity for me to become a full-stack developer.

This week, I have been working on the fundamentals of building a website: creating a rough draft using Figma, defining APIs in Notion, setting up the file structure with Visual Studio Code, and initializing database using DCL, DML, and DDL.

I decided to name a website Quad, name after the area at UOA where students gather and have meal together. For the backend, I will be using Spring Boot and java, while the frontend will be built with React and TypeScript. MySQL will be the database at the moment, though that may change later.

Logo

Each circle, tilted triangle, and square represents students from diverse backgrounds. The heart symbolizes the love we share and receive in our campus!

Rough draft created in Figma

The most important thing I focused on while designing the website was ensuring that the reviews are well-categorized by its department and study so that users can easily find the review they are looking for.

Visualizing API structure

Link to the API document

An API document is a structured document that organizes API endpoints by their addresses. It includes details such as HTTP methods, API addresses, variable names, data types for requests and responses, and HTTP status codes.

Creating an API document offers several benefits. In real-world development, an API document is can be used to enables frontend developers to work independently without relying on backend data. By mocking API responses, the frontend can proceed with development without waiting for the backend to be completed.

However, as a full-stack developer handling both frontend and backend, the primary reason for creating an API document is to synchronize types, variables, and error handling between the two sides. Mismatches between the frontend and backend can lead to various issues, such as API request failures due to type errors and unexpected database behavior such as saving data in wrong data type. These reasons are also why I chose to use TypeScript instead of JavaScript, ensuring stricter type consistency.

Put vs Patch

Both PUTand PATCH modify data in the database, so how do we decide which one to use? The main difference is that PUT replaces the entire resource, while PATCH updates only specific fields (partial update). This distinction might seem ambiguous at first. For example, in Quad, there is a like feature where users can toggle their like status on or off by clicking a button. I decide to implement like toggle feature by creating or deleting a Like Entity. Since I am dealing with entire resource: the Like Entity, I used PUT method instead of PATCH method.

Then why am I not using the POST method, even though I am creating a Like Entity?

The reason is that POST is not idempotent, meaning that sending the same request multiple times does not guarantee the same response each time. However, I want my LIKE feature to behave consistently every time it is called, ensuring the same result regardless of repeated requests. These are the only two behaves that I want like feature to have:

​ 1. If the user has already liked the review, the LikeEntity is deleted.

​ 2. If the user has not liked the review, a new LikeEntity is created.

Therefore, I considered using the PUT method instead of the POST method, as it is more efficient to handle both actions within a single request.

On the other hand, for editing a review, the server does not create or delete the entire review entity. Instead, they update specific fields in ready-written review such as title, content, and rating with new values.

Only certain fields in Review Entity are being modified, PATCH is the better choice for this feature.

DCL, DDL and DML

Okey! We have just finished defining what data and types we need for this website. Let’s start granting database access, creating database tables and manipulating them by adding mock data. SQL command can be categorized into three types: DCL, DDL and DML.

1. DCL(Data Control Language) is used for user access control and permissions. It grants or restricts privileges on database objects. For example, DCL command below grants Kim the ablility to SELECT, UPDATE, DELETE and INSERT on thisWebsite database.
2. DDL(Data Definition Language) is responsible for defining the database structure. Common DDL commands include CREATE, ALTER, and DROP. They affects the structure of table, but not the data itself. We can define column names and data types when creating a table using the CREATE query, modify the table structure with the ALTER query, and delete a table using the DROP query.
3. Now that we have granted user a permission using DCL and defined the table structure using DDL, it is time to actually inject mock datas and check if the features are can work correctly. DML(Data Manipulation Language) allows us to insert, update, retrieve, and delete individual records in the database. The example below shows how to insert a new course into the course table using an INSERT query.