wichat_es3b

To ensure the correct functionality of the application, we performed extensive testing. This included load testing to evaluate performance under high demand, and coverage testing to verify that all critical parts of the code are properly tested. These efforts help guarantee a stable and reliable system.

Both Question and Hint API will make use of external services (SONAR and Wikidata), and therefore will use their APIs.

When the application runs, Wiki Question Service checks the number of questions of each of the five available thematics in database. There are two posible stages: A thematic has not enough questions: If a thematic does not reach a minimum of 60 questions in database, the service will use Wikidata API and SPARQL to generate as many questions as needed, and stores them in database.

A thematic has enough questions: If there are already enough questions, the service substitutes 10 questions of that tematic with another 10 different questions, in order to ensure their variety.

A user wants to create a new account. The user introduces the required information and clicks the "Sign Up" button. The system validates the information and creates a new account. If all the process runs correctly, the system displays a success message

A user wants to log in into the application. The user introduces the required information and clicks the "Log In" button. The system validates the information and if the user had already an account, redirects them to the main page.

When a user asks to start a new game, the system is expected to retrieve 10/20/30 questions of the chosen thematics from its database, depending on the game mode. This will be done before starting the game.

Once the questions are retrieved from the database (previous diagram), the game starts. A user will send an answer to each of the questions of the game. The system validates them and computes the score depending on the time spent in answering the question. At the end of the game, the front-end sends a request to save user statistics in database.

A user wants to get a new clue for the current question. The request is redirected to the LLMService that handles the connection with the real LLM. Once it is processed, it is displayed in the game front-end.

A user asks to see the ranking of the players with the 10 most high scores in a single game. The request is processed by the Stats Service and is returned and displayed to the user.

A user asks to see another user’s game statistics (or their own). The request is then redirected to the stats service, which processes the request and sends a response for the specific user. This data is displayed in the profile view.

A developer user requests for a private API Key in order to integrate our services in their applications. The user provides an email and the system checks if it is registered in its database. If it is not, it displays an API key for the user to store in a safe place.

The user wants to use the API in order to get game questions in return. The system processes the request and returns the questions to the user.

A user wants to check the stats of a user through the API. The system loads the stats of the user asked for.

Below is a diagram summarizing the infrastructure distribution:

This section provides a detailed view of selected infrastructure elements from Level 1.

We have decided that our architecture will be based on microservices,but as the services are not fully decoupled at the data level it’s more accurate a service-oriented architecture, which means that every part of the aplication will be divided in a service that performs a specific function. The services can communicate witch eachother using their repective APIs or via the shared database.

The project follows a CI/CD pipeline that automates build, test, and deployment processes using GitHub Actions. This ensures that the application is always up-to-date and functioning correctly.

We have performed both coverage testing to ensure that key parts of the application logic are tested, and load testing to verify performance under heavy use. These tests help ensure a stable and reliable system.

Deployment is handled in two environments: locally using Docker containers for development and testing purposes, and in the cloud via Microsoft Azure for production deployment. Each service runs in a container, and the frontend is exposed through a public IP address.

Usability is crucial for any application, as it directly impacts user interaction efficiency. To ensure our app’s usability, we conducted extensive user research, leading to an intuitive interface design. Employing a user-centric approach throughout development, we prioritized user experience, facilitating easy navigation.

We have implemented internationalization (i18n) to support both English and Spanish. This includes not only the user interface but also the question content, ensuring that the entire experience is localized based on the user’s language preference.

The application includes a monitoring setup using Prometheus and Grafana. Prometheus collects real-time metrics from different services, such as request rates, response times, and error counts. These metrics are visualized in Grafana through custom dashboards, which help the development team track performance and availability.

This setup allows early detection of anomalies or bottlenecks, ensuring a stable and responsive user experience.

We need to integrate a Large Language Model (LLM) into our question-and-answer application to generate hints during the user’s turn. Therefore, we decided to use the LLM models associated with the API key provided by the teachers.

Decision:

It was decided to integrate Large Language Models (LLMs) through external APIs to generate real-time responses and hints.
The selected models are Mistral-7B-Instruct-v0.3 and Qwen2.5-Coder-7B-Instruct, both from Empathy AI because it is the API key that has been provided to us and allows us to access both easily with the same API key, improving our resilience in case of external failure by any of the models .

Consequences

Consequently, we need a structured knowledge source, in our case Wikidata, from which we will extract and process the information to provide it to the user and also we must learn to create effective prompts.

To know more about Prompt Engineering Issue #4.

We needed to use Wikidata, so we chose SPARQL to construct queries and retrieve the associated information.
Decision made in Acta 2 ‐ 10 02 2025.

Justification

Consequences

To learn basic concepts about Wikidata and SPARQL Issue #6.

We require an efficient framework for frontend development so we decided to utilize React for the user interface.
Decision made in Acta 2 ‐ 10 02 2025.

Justification

As a consequence, most part of the team will require React training because it is a new technology for many of us.

To learn basic concepts about React Issue #7.

We require an efficient and scalable technology for the backend so we will utilize Node.js to solve this problem.
Decision made in Acta 2 ‐ 10 02 2025.

Justification
Node.js is highly efficient for asynchronous and high-traffic applications. Furthermore, it is a great opportunity for many of us to learn how to use this important technology in the software development world.

New knowledge about Node.js Issue #3

Due to the requirement for flexible storage of structured and unstructured data, we have chosen a NoSQL database over SQL.
Decision made in Acta 2 ‐ 10 02 2025.

Justification

Consequences
Query optimization may be required for handling large data volumes. Although we have had some exposure to NoSQL databases, further training and development in this area will be necessary to optimize their usage. If we need a bigger version of the database, we will have to pay for it.

To learn basic concepts about MongoDb and practice examples Issue #9.

Considering the need for a dependable, scalable, and efficient deployment process, we chose Docker to containerize our services. Docker allows us to define and package all the components of our application in a consistent and repeatable manner, making it easy to deploy across various environments without issues.

Justification

Consequences

We chose JavaScript (Node.js) for the backend because using the same language on both the frontend and backend simplifies development and improves team collaboration.
Decision made in Acta 2 ‐ 10 02 2025.

Justification

Consequences

We need to implement an API service to provide access to user data and the questions generated. To achieve this, we will deploy it as a separate service in its own container.

Justification

Consequences

We need to ensure that our application can handle a large number of concurrent users and requests. To achieve this, we will use Gatling to perform performance tests on our system.

Justification

Consequences

We need to monitor our application to ensure its performance and reliability. To achieve this, we will use Prometheus for data collection and Graphana for visualization.

Justification

Consequences - Learning curve: Some team members may need to familiarize themselves with Prometheus and Graphana and their configuration. - Integration: We need to ensure that works on local and remote environments, which may require additional configuration and testing.

Although we could have used an existing project as the foundation for our application, we chose to build it from scratch and instead use other repositories only as references.

Justification - Customization: By starting from scratch, we can tailor the application to our specific needs and requirements without being constrained by the limitations of an existing project. - Familiarity: It’s easier for the team to understand and maintain the codebase when we build it from the ground up, rather than trying to decipher someone else’s code.

Consequences - Higher initial effort: Starting from scratch requires more time and effort to set up the project and implement the necessary features.

We decided to implement an authentication system for the API service to ensure that only authorized users can access the data and functionalities it provides. Authentication is based on the user’s email, which is stored separately from gameplay data to avoid exposing sensitive information and to allow non-player users to access the API securely.

Justification - Security: By implementing an API key system, we can control access to the API and prevent unauthorized users from accessing sensitive data or services. - Improving the overall value of the API: By requiring an API key, we can track usage and monitor performance, which can help us identify potential issues and improve the overall quality of the API.

Consequences

Due to errors encountered during the deployment process, we decided to customize our build pipeline to ensure the application remains in a consistent state and that all tests are successfully completed before deploying to production. The default configuration only runs unit tests, but we also require all end-to-end tests to pass before any production deployment.

Justification

Consequences

We decided to use Azure as the deployment environment for our application.

Justification

Consequences

To ensure a consistent and balanced number of questions per category in the application, we decided to preload and normalize the question sets during application startup.

At the moment the application starts, each question category will be processed to ensure exactly 60 questions are available:

Justification

This approach ensures that all categories offer a uniform and fair gameplay experience by maintaining a consistent number of questions, avoiding categories with too few or too many. It also guarantees regular content refreshment in overpopulated categories to prevent repeated questions and improve user engagement. Additionally, centralizing this logic at startup simplifies runtime operations and reduces delays during the user’s turn.

Consequences

We can observe that the code coverage is ~82%, which is above the threshold of 80% set in the quality gate. This means that the code is well-tested and meets the quality standards. Also, 0.9% hotspots are presented, which means that the code does not contain any known big vulnerabilities.

We have a total of 15 E2E tests, which cover various scenarios and user interactions, like login, logout, signup, access the profile, access the ranking and play both Single Player and Player VS AI game modes with different configurations.

We try to cover all the possible scenarios that a user can encounter while using the application. Ensure all the code is covered is almost imposible, though.

These tests are run automatically as part of the CI/CD pipeline to ensure that the application works correctly after each change.

We have done several tests to identify exactly the capacity that the app can support.

So this is where we’re going to stop and look at the graphs we get from the test results:

These graphs reveal that the system experiences significant degradation under load, with specific points of failure at certain endpoints and response times deteriorating markedly as concurrency increases.

Furthermore, we can also conclude that the question service acts as a bottleneck in the application.

On the other hand, we see that in addition to the question service, the LLM begins to cause problems starting at about 750 users, as shown in the following table: * The request_1 represents the OPTIONS request, while the request_2 represents the POST request.