The system design is created with a Vite/React frontend and Tomcat for the backend, using a MySQL database for storage. One decision we made was to create a website with page routing, breaking up different pages into smaller components. There is a Welcome Page, separate from the Category Page. There are different components for the /AppHeader, /CategoryBookList, and /CategoryBookListItem. Different components allow for isolation of codes, making testing and reusability much easier. It also allows for independent pages, where if one page is not working it does not hinder the entire website. We also used the Context feature of React to keep all the data in one shared “/App” component, that all other components have access to and can retrieve data from. This prevents the system from having to pass data through components constantly, simplifying code and making the program less cluttered. Additionally, since data is not passed through, if one component fails, other components are still able to retrieve data that they require from the centralized storage. Additionally, in \CategoryBookList page, there is a fixed number of books that are retrieved and displayed at one time. This is so that the front end is less cluttered, and that website performance and latency are not impacted whilst browsing books.  

The frontend and backend communicate with REST API calls, rather than a direct channel. This allows for a clear separation of responsibilities and makes the system modular rather than one big program. The backend will also handle all authentication and login requests. This allows for effective encryption of sensitive data and allows the backend to handle all login requests to ensure that sensitive information cannot be accessed through the GUI. Additionally, the backend will handle all LLM prompt and recommendation responses to suggest books based on user history, search requests, and compiled metadata. This will allow the frontend to create a much more personalized profile and prevent clutter as all the data is stored in the backend. The backend will also provide support for the MySQL database used in the system. MySQL provides a strong relational database when coupled with indexing and normalization can provide easy seamless retrieval through REST API calls.  

This layered architecture approach separating frontend and backend will provide an efficient LLM system and database management process. Additionally, this design will make it easier to update and fix bugs and test changes without having to test the entire code. This also allows for an easier ability to add new features due to modularity.  

How design meets quality goals 

1. Performance  

 Goal: Fast constant page loading, smooth and instant scrolling and navigation. 

Firstly, all the pages are isolated, and only one page is loaded at a time at the user's request. This makes each page run faster and only requires a portion of data to be loaded at a time to improve network latency. Additionally, when a user is trying to access a list of books, a fixed amount is shown on any given page. Sectioning search results into smaller chunks ensures that the page doesn’t slow down for user searches. Additionally, each picture and image is scaled to the device the page is opened up to. Showing pictures based on display size will make it so that display quality and speed is not impacted. Additionally, using a combination of HTTP for memory caching and reloading, and CSS and React for a dynamic frontend will create a high-performing, low latency and secure GUI. Lastly, due to REST API being used to connect the frontend and backend, the speed at which user requests are processed will also be of a high quality.  

2. Scalability  

Goal: Maintain high level of scalability regardless of client user request or number of users on the website. 

Using a large and very easily updatable database through MySQL, the website should maintain similar speeds regardless of how many books are stored in the virtual library. The backend will be created using indexing and normalization to support optimized query retrieval for fast data retrieval regardless of the amount of data. Data will also be stored in one large pool using a React Context design framework, and only required parts will be pulled for the corresponding request, so that large amounts of data do not have to be retrieved, maintaining a high speeds regardless of the number of users.  

3. Reliability 

Goal: To maintain a well-designed and efficient system.  

The backend will be programmed to handle and maintain all sensitive information. This will include user login and authentication, order purchases, and payment information. This is to ensure that information of this nature is properly encrypted and not accessible through the front end. Additionally, there are error countermeasures in the front end. In the case that the user interface runs into an error, a React fallback message with helpful information will be displayed rather than crashing. Due to the modularity of the program, developers will be able to easily find and eliminate bugs and dysfunctional implementation. Furthermore, the layered architecture will ensure that if one service fails, the rest of the functions in the application will continue to work, ensuring that users can checkout and process payments without any issues. Due to data being stored in a shared Context rather than being passed along every frontend component, if any part of the application becomes corrupted, users can rest assured that their data and information will stay intact and secure.  

4. Security  

Goal: Protect all sensitive information and prevent any data breaches.  

Security is a high priority for an application that involves authentication and constant payment processing. We have designed the backend to handle all authentication attempts, order requests and payment processing, and information. All of this information is hashed, encrypted, and stored in secure cookies to prevent hacking attempts. MySQL will enforce constraints to avoid leaks, data corruption, and accidentally displaying sensitive information in the front end. The backend built with Tomcat and Jakarta EE will ensure that users only access resources and information associated with their account. The REST API endpoints and channel will be validated in the backend with output security to prevent injection vulnerabilities. Additionally, the LLM will be secured in the backend to prevent user preference and behavior of data from being accessed by data breaches. 

5. Usability

Goal: Create a friendly, intuitive front-end that can be easily learned by all users. 

The system is created with a constant navigation feature, where users can easily switch between the Welcome, Category and Checkout page. Additionally, all images and layout formats are automatically adjusted based on screen size so that the website is easy to use across all devices. Additionally, all of the web pages are well-defined and clearly labeled, such as the "Suggestions" section on the Category page, or the process of inputting information in the Checkout page. This way, users are able to easily understand how to use the website, and understand all of the functions across all pages. 

Main Risks and Mitigations 

Many of the risks come with our security features that work to keep data and information secure. The first risk would be API injections, which can lead to data breaches as the REST API endpoints have access to our MySQL database. To counter this, we can enforce strict server validation to only allow secure queries to go through. Additionally, another security risk is exposed credentials and authorization secrets. To solve this, we would store all the secrets in a vault and ensure that the keys are only valid for so many days before they need to be updated. Lastly, we also need to focus on mitigating authorization risks. To do so, we would have to ensure strict location and IP validation, as well as enforcing HTTPS protocol and password hashing and storage to prevent leaks. Another risk comes from our implementation of LLMs and AI suggestions. We will be collecting and using user preference and activity data in order to provide a more personal experience. Because the API endpoints will have to have access to the AI in order to prompt recommendations, API injections may lead to sensitive user activity from being accessed and leaked. One mitigation is using limited API endpoints for the AI, so there are less avenues for access to hackers. Lastly, one of the most common risks for websites is a data breach that leads to exposed credit card and financial information. Payment endpoints are very prone to being targets of data breaches so it is very important to safeguard those to prevent theft and fraud. One way to prevent this is to never save CVV's and expiration dates of cards. Rather, the system can verify that information against a banks information and ensure it is correct, and delete it so that even if there is a leak critical information required to use credit and debit cards are not exposed. Additionally, adding a fraud detection security feature such as usually large orders and suspicious IP address usage.