About arc42
arc42, the template for documentation of software and system architecture.
Template Version 8.2 EN. (based upon AsciiDoc version), January 2023
Created, maintained and © by Dr. Peter Hruschka, Dr. Gernot Starke and contributors. See https://arc42.org.
1. Introduction and Goals
The application aims to be a web game of questions and answers following the format of the TV show ‘Saber y Ganar’. The game will show a question to the player followed by a fixed number of possible answers (the information used in the questions and answers will be obtained from Wikidata. The player must answer these questions by clicking on one of the answers, clicking a correct answer will increase their score and clicking a incorrect answer will decrease it.
The description given till now was the same as the project that was implemented by the students that took the software architecture course last year. But, apart from that, this year there will be a new feature that implements a clue system using an LLM. This system will let the user decide whether to use clues or not once they have seen the question. Some goals established for the application are (without priority order):
-
The game should implement all the functionality of the ones developed the previous year
-
The game should integrate a hint system that uses LLM technology.
-
There should be a good quantity of questions and answers to be asked in the game. (considering that the information for this Q&As must be taken for Wikidata)
-
There shall be a log in in the application that allows users to obtain historical data from their participations.
1.1. Requirements Overview
1.1.1. The functional requirements
About the Game service:
-
The game shall correctly show the questions and all the possible answers.
-
The game shall manage the answers given by the player as expected.
-
The user interaction with the clue system shall be managed.
-
The application should be accessible through the web.
-
There shall be a time count down in the game questions.
About the Hint service:
-
The user should be able to ask for hints from the LLM in each question
-
The system shall give access to information about questions through an API.
About the Wikidata service:
-
Each question must have a single correct answer and at least one incorrect answer
-
The questions shall be obtained from Wikidata.
-
The questions shall come with an image obtained from Wikidata.
About the Users service:
-
The system should give non-registered or unidentified users the option to register to the application There shall be a record of the historical data of the games from logged in players (number of games, number of failed questions, …).
1.1.2. The non-functional requirements
About the Hint service:
-
An specific approach should be use to avoid incorrect answers and hallucinations from the LLM
-
The LLM clue system should be implemented so it gives quality clues.
1.2. Quality Goals
Regarding the Hint service, the implementation of tests and that the product is extensible is one of the main goals as they are one of the most important requirements of some of our stakeholders (our teachers)
The quality goals we have considered the most important taking into account the necessities of our major stakeholders are the following 5:
| Goal | Description |
|---|---|
Availability |
The system shall be available 97% of the time a user tries to access |
Usability & Operability |
The application is intuitive, an inexperienced user can understand by himself how to play each game in less than 5 minutes. |
Security |
An unauthenticated user can’t access the game and the data of the users can only be accessed by themselves with their encrypted password. |
Functional suitability |
The system will have a user management system that will allow users to login with their credentials stored, sign up if they aren’t registered, and see their historical data (scores). The system has a game system that will allow to obtain reliable questions from wikidata, and ask the LLM for hints |
Reliability |
The failure of the LLM doesn’t translate into the failure of the whole application. There will always be some questions available for playing due to the diversity taken into account |
1.3. Stakeholders
| Role/Name | Expectations |
|---|---|
Users |
Test their knowledge while having fun. |
Software architecture professors |
Provide their students, the development team, with practical experience regarding software architecture by allowing them to work in an environment that emulates the flow of development of a real project. Which means that they expect us to be able to meet the standards of quality and production of a real application. |
RTVE |
Get an evolution of their quiz game and continue promoting their program all around the world |
ChattySW |
Develop an application within the given constraints and that fulfills the requirements given by the client |
Offer a service allowing the development team to create the questions using an API |
|
Google Gemini |
Offer a service allowing the development team to provide hints using an API |
2. Architecture Constraints
The application has some constraints, these are requirements of the stakeholders or environment that we must accept. They are divided in technical constraints, organizational constraints and convention constraints.
2.1. Technical Constraints
| Constraint | Limitations |
|---|---|
Web Frontend |
The system will have at least a Web frontend |
Deployment |
The application should be deployed in the cloud with Azure or a similar provider |
Wikidata |
We must use Wikidata to get information to generate the questions |
LLM |
An LLM will be used to generate hints for the questions |
GitHub |
We must use GitHub for the version control of the project |
Testing |
We must have unit, acceptance and load tests at least. With a code coverage of at least 80% |
Documented API |
We must have a documentation of the APIs created using OpenAPI |
2.2. Organizational Constraints
| Constraints | Limitations |
|---|---|
Team |
The team for the project was chosen by the professors |
Weekly meetings |
There must be at least one weekly meeting |
Public repository |
The project source code will be available in a public repository |
Continuous Integration |
The project has some requirements stated by our stakeholders will be automatically checked or done using GitHub actions: a code coverage of 80%, no more than 3% of code repetitions, deployed… |
Documentation |
It should be complete, deployed and synchronized with the application’s arquitecture |
2.3. Conventions
| Conventions | Limitations |
|---|---|
Documentation architecture |
The documentation must follow Arc42 |
Language |
The documentation and in general the project will be written in English |
3. Context and Scope
3.1. Business Context
-
User: the player interacts with our application by using the front-end of the application to sign up, log in, and play different games (question game, akinator style game, and wordle game)
-
Application : our application allows the player to play the games, and it will interact by using queries to get the questions, answer and incorrect options from WikiData, and getting hints for the different games from the LLM. It also allows the user to authenticate and see their score.
-
Login and SignUp: authentication system for the game.
-
Scores: score system that allows users to see their past games statistics.
-
WikiData: API to extract the information for generating the different questions, options and answers.
-
LLM: API to ask to an AI for hints related to the question shown to the user.
3.2. Technical Context
The application is deployed using Docker with Oracle. The whole application: The user interacts with the front-end of the application. It will be a SpringBoot project called webapp that will contain the user interfaces and ask the other parts/services of the application the different data that it needs. So, it acts as a Controller.
The services will be:
-
UserService for the Login, SignUp and Score system. It will interact with the database (MongoDB) by using the TCP/IP protocol and sending queries in JSON format for the user authentication, and their statistics for the different games he played.
-
WikidataService which will interact directly with Wikidata by using the HTTPS protocol and sending some queries in SPARQL. Also, it interacts with the database (in the same way as the UserService) for storing the questions for the game.
-
HintService which will interact directly with the LLM by sending some queries and instructions using the HTTPS protocol and Google Gen AI Java SDK.
The services are deployed as images in Docker with Oracle, and are different SpringBoot projects that act as REST APIs.
4. Solution Strategy
4.1. Technology breakdown
4.1.1. Backend
| Decision | Reasons |
|---|---|
Use SpringBoot at the project |
We are going to use SpringBoot at the project because: - It gives us a lot of functionality already implemented so that we don’t have to implement it ourselves (security, validators, exception handler, default configuration…). - It allows us to use Java, which we are very used to and prefer over JavaScript. |
MongoDB as a database system |
We will use MongoDB because: - It’s already integrated in the user and authentication service - It’s the more popular non-relational database, and has a more or less simple syntax |
Creation of an entities project |
We created an entities project that contains entities that are used by several services (webapp, hintService, userService…) for avoiding code duplication, reutilize code and avoid mistakes caused by repeating code. |
4.1.2. Frontend
| Decision | Reasons |
|---|---|
Use SpringBoot at the project |
We are going to use SpringBoot at the project because: - It gives us a lot of functionality already implemented so that we don’t have to implement it ourselves. - It allows us to use Java, which we are very used to and prefer over JavaScript. |
Use Thymeleaf as template engine |
Use of Thymeleaf as template engine: - It’s easy integrated with SpringBoot - It allows us to separate the user interface from the content in the web application, process model data dynamically and access to model attributes |
4.1.3. LLM
| Decision | Reasons |
|---|---|
Gemini as the LLM for generating hints |
We will use Gemini because: - It has a free api usage with limitations, but it is enough for our application. - It’s already integrated in the llm service. - It has a way to handle hallucinations and errors. - It allows us to send the instructions for how the LLM should behave each time the user asks the LLM something. This also means that the user can’t just ask the LLM to ignore its instructions and give them the correct answer. |
Use of Google Gen AI Java SDK as API |
We use GenAI for communicating with Gemini as: - It’s very easy to use as it’s well documented - It simplifies the communication to Gemini, as you don’t need to use JSON in Java with difficult configurations. |
4.1.4. Deployment
| Decision | Reasons |
|---|---|
We will use Docker with Azure because: - Docker containers encapsulate the application and its dependencies, ensuring consistency across different environments (development, testing, production). - This portability allows seamless deployment on Azure, regardless of the underlying infrastructure. |
|
Use of Docker with Oracle for deploying the application permanently (instead of Azure) |
We will use Docker with Oracle because: - It’s much more cheaper than Azure for keep the app deployed. |
4.2. Toplevel decomposition
| Decision | Reasons |
|---|---|
MVC architectural pattern |
We will use MVC for the project because: - It allows us to divide the application into model, view and controller and are less coupled. - Easier for developing and scalability since all layers are separated, making easy to change one layer and divide the work |
Microservices architecture |
We will use the microservices architecture because: - We can divide the project into independent services (other projects) that can be reusable. - This allows flexibility to change how each service works, having independence to develop each service on it’s own, and easier to update them since they are not coupled. |
4.3. Organizational breakdown
| Decision | Reasons |
|---|---|
Weekly meeting |
Up until this moment we are meeting only once a week because: - We can work together at class in person - We can be up to date with the things done, discuss the future decisions and see what problems each teammate have - Everyone can have a moment to express themselves |
WhatsApp group |
We are using a WhatsApp group as a secondary way of communication because it’s a common application for all of us and it can be accessed anywhere. |
GitLab Flow as branching strategy |
The branching strategy ‘GitLab Flow’ will be used by the development team because: - It is the branching strategy that fits better the team and project characteristics. - It’s simple as it only has 3-4 types of branches. It’s less complex than Gitflow but more structured than Github Flow. - It’s well divided, and allows simultaneous work on different features |
4.4. Quality decisions
| Attribute pursued | Choice |
|---|---|
Availability |
To ensure the 97% availability of our system, we use a virtual machine from Oracle who is a trusted provider. |
Usability & Operability |
The application features a user-friendly UI that allows it to be easily understood. The application can be used with no training as it provides tooltips describing instructions for the games for new users. |
Security |
We use SpringBootSecurity features to force the user to login to access the application. When registering a user, we use PasswordEncoder to encrypt the password so we don’t store their raw password in our database. |
Reliability |
There will be always questions available to play, since we load the questions when starting the application. |
Compatibility & Transferability |
The application has been design to work in all modern browsers while providing equal performance. For that, we made use of HTML, CSS and Bootstrap. In addition, since the application is designed to be deployed with Docker, it can be transfered to another computer or device with no issue. |
5. Building Block View
5.1. Whitebox Overall System
Motivation
This is a very general overview of our system to understand how it works and services has/uses in a simple way.
Contained Building Blocks
As we described, before it’s composed by:
-
A User that will interact with our application.
-
Our application will interact with different services: Login and SignUp, Scores, WikiData and LLM.
Important Interfaces
The user interacts connects to the application and can play the game by making
5.2. Level 2
Motivation
This gives a little more deep that help us to understand the architecture and how we structured.
Contained Building Blocks
-
The WebApp provides the user interface of our system. It could be considered the Application, but it works as a Controller, that is an intermediate between the User and Services provided.
-
UserService is a REST API that provides all the functionality related with the users (login, sign up, scores of users). It also, communicates with the database for making the authentications and retrieving or storing scores of the users.
-
WikidataService is a REST API that is in charged of generating the questions from Wikidata, and stores them in the database.
-
HintService is a REST API that is in charged of communicating with the LLM (it’s an intermediary), so it sends prompts to the LLM with some context.
Important Interfaces
The webapp provides the user interface, contains the logic of the games and communicates with the rest of services by using making requests to their REST APIs to provide its functionality.
5.3. Level 3
Motivation
This level gives a more detailed and clarification specially for the webapp, as it can be considered the most complex element.
Contained Building Blocks
-
The services we mentioned before.
-
The UI (User Interface) forms part of the webapp, and it’s going to the intermediate between the User and the logic of our system.
-
The question game is in charge of managing all the logic regarding this game, and will make requests to the services. For example, for getting hints to the HintService…
Important Interfaces
The webapp follows a MVC architecture, so we have the view with controllers that manages the requests made by the User, and the Question game is divided into Services (the real logic of the game), Repositories (they are in charged of making requests to the UserService, HintService and WikidataService) and Entities.
Also, the entities that are used among several services/modules/projects are extracted into an entity module/project that is used as a library from teh rest of the system.
6. Runtime View
6.1. Sign up
The following diagram shows how the sign up process of a user is done.
-
The client writes the credentials needed to create and account.
-
Check the credentials are valid in format.
-
Check that the fields that need to be unique are unique.
-
Returns if they are unique.
-
Create the user and store it in the Database.
-
Notify to what page the user should be redirected.
-
The user is redirected to the login menu.
-
Notify that the credentials are invalid.
-
The errors are shown and the user isn’t registered.
6.2. Login
The following diagram shows how the login process of a user is done.
-
The client writes the credentials needed to login.
-
Check the credentials are valid in format.
-
Check the credentials are valid for the user.
-
Return if the credentials are valid.
-
The user is authenticated.
-
The user is redirected to the home menu. The user can access to its statistics and play games.
-
Notify that the credentials are invalid.
-
The errors are shown and the user isn’t registered.
6.3. Question game
The following diagram shows how the playing of the game is done.
-
Choses the question game option and category in the menu.
-
The game starts.
-
Ask for a random question to WikidataService
-
The data related to the question is returned.
-
The question and available options is shown to the User
-
User asks for a hint.
-
The timer is stopped.
-
See the Hint Generation section below.
-
The information related to the hint is returned.
-
The hint is shown to the User
-
User choses an option from the four given.
-
Check if the option picked is the answer or not to the question.
-
The User is informed if they make a good guess or not.
-
Sends the results and information of the game by using the UserService.
-
The UserServices sends this information to the database to be stored
-
The information of the game is shown to the User.
6.4. Question generation
The following diagram shows how the generation of the questions is done. This option loads the questions during the game directly from Wikidata.
-
The WikidataService requests questions about several topics.
-
Wikidata returns the question, answer and image for the question.
-
The WikidataService send all the questions to the Database, so they are stored.
6.5. Hint generation
The following diagram shows how the generation of the hints is done.
-
The WebApp (after the user asks it) asks for a hint to the current question, and gives instructions and context for the LLM.
-
The HintService gives some context to the LLM, and asks for a clue.
-
The LLM returns the clue.
-
The HintService returns the clue.
7. Deployment View
7.1. Infrastructure Level 1
Motivation
The above diagram shows the initial version of the architecture and the division between its components. We will be using a microservices architecture, with a main server that the user directly interacts with and several services that this server interacts with. One of these services interacts with Wikidata to get questions, another interacts with the database to store user information and another interacts with Gemini to get hints and more.
Quality and/or Performance Features By separating the architecture in this way we have a lot of separation, which provides flexibility, expandability and scalability. The services could be changed and as long as the API remains the same, everything would keep working.
Mapping of Building Blocks to Infrastructure
-
The webapp is in the webapp folder
-
The userService is in the userService folder
-
The wikidataService in when wikidataService folder
-
The hintService in the hintService folder
-
The database runs in Docker, and upon WikiData service starting it will be filled with questions
-
WikiData is an external component, which is key to our application but is not something we can change, it’s important to keep up with any API changes and to keep in mind that information there might be wrong our outdated.
-
The Grafana configuration is in the Grafana folder
-
The Prometheus configuration is in prometheus.yml
8. Cross-cutting Concepts
8.1. Domain model
Classes
-
Question: Represents a question entity. It contains the question text, a list of possible answers, the correct answer, and optionally an image relevant to the question. Each question is associated with a question category.
-
User: Represents a user, storing personal information such as name, email, and password.
-
Answer: Represents an answer entity. It contains the answer text and is linked to an answer category.
-
Score: Represents the score for a game session. It records key information such as the user who played, the game category, the number of correct and incorrect answers, and the time taken to answer the questions. It’s linked to a User
Enums
-
QuestionCategory: Defines the categories of questions. The current available categories are Pop Culture, Biology, Sport, and Geography.
-
AnswerCategory: Defines answer categories related to the question categories, such as Flag, Brand Name, F1 Team, Monument Name, Animal Lifespan, and others
8.2. User Experience (UX)
As our goal is to develop a game, the user experience has a huge rol, as players must enjoy playing. To achieve this, we developed interfaces that are intuitive, with instructions and colorful.
8.3. Safety and Security concepts
We use Spring Boot Security features to require users to log in before accessing the application. During user registration, we employed PasswordEncoder to encrypt passwords, ensuring that raw passwords are not stored in our database.
8.4. Architecture and design patterns
We chose to use Spring Boot for both the backend and a Thymeleaf-based frontend, following the MVC pattern to keep the codebase clear and well-organized. Also, we used microservices to have a project divided in clear and independent modules that are reusable.
We use MongoDB as our database system to store information about users, scores, answers and questions.
8.5. Development concepts
We will deploy in Oracle using continuous integration.
8.6. Our decisions
To ensure the application’s robustness and high availability, we adopted a microservices architecture with a clear client-server division. A key design objective was to make the application independent of external services such as Wikidata and the LLM. This ensures that even if these services experience timeouts, our application remains available to users without interruption. To further minimize delays caused by Wikidata, we implemented multithreaded access when retrieving data, improving performance significantly. This modular approach enhances resilience, scalability, and fault tolerance while keeping a clean separation of concerns between data fetching and data usage.
9. Architecture Decisions
9.1. Client/Server architecture
We are going to have an architecture with a main application with a client and server, and several servers for the external services (users, WikiData, LLM, etc.) that will act as data APIs for the main application server. These service servers will respond to requests by returning data that the main application will process and pass to the view. This will provide us more independence between the modules so they can be modified at will without affecting the whole application.
9.2. MVC architectural pattern
We are going to follow and MVC architectural pattern as it allows for a more divided and structured application with low coupling. This pattern works well with springboot, has low coupling, and allows to work independently with front and backend.
9.3. Microservices architecture
We are going to use a microservices architecture as it allows us to divide the whole application’s project into independent services that we can treat as separate projects that can be reusable. With microservices, we would be able to divide the application in small teams that can work independently.
9.4. Backend
We are going to use a springboot. It is reusable, it contains many already implemented funtionalities and we are extremely familiar with the language (Java).
9.5. Frontend
We are going to use a springboot with thymeleaf. Springboot is reusable , it contains many already implemented funtionalities and we are extremely familiar with the language (Java). In addition, thymeleaf allows access to model attributes, processes dynamically the templates and separates the user interface from the content.
9.6. Databases
We are going to use a non-relational database, MongoDB for the whole system. It is easier to use just a single database system for the whole application. In addition MongoDB is based on JSON so it has a simple sintax with powerful operations and since we don’t need complex relationships works well. It’s also very flexible since a collection can store different document and attribute types without a structure.
9.7. Cloud service
We have decided to use Oracle as our main service. It is less expensive than the alternatives and has good enough availability. We however have decided to have Azure as a backup in case of an issue
9.8. LLM
We have decided to use Gemini since it is very powerful with ways to control hallucinations, allows instructions on the llm’s behaviour, free of charge usage.
10. 10. Quality Requirements
10.1. Quality Tree
All the quality requirements for the systems are:
Here there are the rest of quality attributes that we don’t considered as much important as the mentioned before.
| Quality Attribute | Requirement |
|---|---|
Performance efficiency |
Since the main game relies on generating questions and showing an image, the application should be able to generate them efficiently and to render the image within a short time. For this, the questions are loaded when the application is first deployed so there is no need to query Wikidata each game. For the images, we use the ones provided by WikiData and display them with a resolution low enough to guarantee a short waiting time. |
Maintainability |
While the end users won’t see it, we want to make sure that our application’s code is maintainable and easily modifiable so new features can be easily added without the need to change a lot of the previous code. To ensure this, we chose a modular architecture (MVC and microservices) to reduce coupling between elements and included tests to verify that they work properly in case there are modifications. |
Compatibility |
The application has been designed to work on most moder browsers to ensure that the users can access it and use it regardless of the technology they use to connect to it. To ensure this, we did a responsive design and using standard technologies (CSS, JavaScript, HTML…) |
Transferability |
Since the application is deployed using Docker, it can be easily transferred to a new machine or cloned into multiple ones to improve scalability |
10.2. Quality Scenarios
Some quality scenarios are:
| Quality attribute | Scenario | Priority |
|---|---|---|
Usability |
When the user enters into the app for the first time, he must understand how to play each game in less than 5 minutes. |
High, High |
Security |
When the user tries to enter the game without registering, it’s access is denied |
High, High |
Reliability |
When the LLM isn’t available, the system should keep working without failing |
Medium, High |
Maintainability |
When we want to change the LLM used, only the part of the system in charged of the LLM should change, and don’t affect the overall system |
Low, Medium |
customer, architect
11. Risks and Technical Debts
| Risk | Description |
|---|---|
User Authentication and Data Privacy |
User registration and historical data storage introduce potential security vulnerabilities (e.g., data leaks, unauthorized access). Compliance with GDPR or other privacy regulations is also a concern. |
Integration with Wikidata |
Extracting meaningful and accurate data from Wikidata for generating questions and hints may be challenging. Data inconsistencies, missing attributes, or outdated information could lead to incorrect questions or hints. |
LLM Availability |
Since we are relying on a free AI model, the amount of requests the application can make is limited. If the number of players is too great, the parts of the application reliant on the AI may not work |
Scalability of the System |
As more users register and play, the backend (Wikidata API, LLM API, and database) may face performance bottlenecks. |
LLM Accuracy |
The LLM may generate incorrect or misleading hints (hallucinations). |
Question Repetitiveness |
Users may encounter repetitive questions. A system for tracking previously used questions and ensuring diversity in topics is necessary. |
Question quality |
Due to the format of some of the questions, some of them may seem "stupid" (asking the name of a logo while displaying the name in the image). As such, an effort should be made to indentify this questions and resolve any issues they may have. |
Time-Limited Question Challenges |
Implementing a real-time timer for answering questions may lead to synchronization issues across different devices and network conditions, potentially causing an unfair experience. Latency compensation mechanisms should be considered. |
12. Testing & Monitoring
A wide range of tests were done to ensure that our system work as expected and ensuring a code coverage greater or equal to 80%. Also, we monitor our system using SpringBoot Actuator, Prometheus and Grafana.
12.1. E2E testing
We implemented acceptance tests to verify that the product meets the specified requirements and behaves as expected from the user’s perspective. These tests were primarily conducted using Selenium, with some scenarios defined in Cucumber.
Some scenarios that were tested with acceptance tests are login with valid and invalid credentials, signup with valid and invalid credentials, logout….
12.2. Unitary testing
Unit tests were implemented to verify that both users and the application behave as expected and do not perform unintended actions. We used JUnit 5 for writing the tests, and Mockito for mocking dependencies where isolation was required. These unit tests also contributed to improving code coverage, in line with our quality gate requirement of 80%. Right now, the code coverage stands at 85.1%.
12.3. Load testing
Load testing was done to ensure the fulfilling of the performance quality goals that we defined in the first section of this documentation. It was done in a laptop in localhost with 12 cores and 16GB RAM.
The tests don’t cover the whole application as we weren’t able to cover the artificial intelligence section due to the limit in requests of Gemini.
We did two different tests for this:
-
The first one was a simple one were we just made the users log in, check their scores and log out.
-
The second one was a bit more complex as we made the users make the same thing as before but also play a Biology question game by letting in each round that the time finishes.
For both test, we were incrementing the number of users in different phases:
-
It started with one user.
-
Then it added 5 users over 10 seconds
-
Then, added 15 users over 30 seconds
-
Then, added 50 users over 30 seconds
-
Then, added 100 users over 120 seconds
-
Then, adding 20 users per second during 5 minutes.
Here we can see the results for the first test:
We can see that:
-
20874 request lasted less than 800 ms
-
2807 are between 800ms and 1200ms
-
10078 take longer than 1200ms
-
10083 failed
-
The pages with more failures were (from more failures to less): login, scores, home and logout.
As you can see the application can handle up to 500 simultaneous users very well, even though some requests started taking long and failing.
Here we can see the results for the second test:
We can see that:
-
185953 requests lasted less than 800 ms
-
18797 failed
-
The pages with more failures were (from more failures to less): view results, scores, home, login and starting the game.
In this case you can see that the application even though it has a bit more failed requests it handles more than 3000 users simultaneously so that increase is expected. This might be because the users might be distributed in different pages and also the players aren’t really playing.
From these results we can see that is needed to be checked if it can be improved the Scores pages and Home specially, as they are always very high in terms of failed requests and they are also very common pages tha tusers usually visit.
12.4. Monitoring
The Prometheus actuator is deployed in https://wichat.pablordgz.es/actuator/prometheus. And the Prometheus server is deployed in 158.179.214.177:9091, but the port is closed as you can accessed the statistics using Grafana. But also is deployed for each service: userservice.wichat.pablordgz.es/actuator/prometheus, wikidataservice.wichat.pablordgz.es/actuator/prometheus and hintservice.wichat.pablordgz.es/actuator/prometheus.
Grafana is deployed on port 3001, and can be accessed for the webapp using the following URL https://gf.wichat.pablordgz.es, and the credentials: admin (as user) and nice_dashboard (as password). The dashboards used are JVM micrometer and SpringBoot observability.
13. Glossary
| Term | Definition |
|---|---|
WikiData |
Large database containing information from multiple subjects that’s free to access and open to modifications. We will use it to generate questions for the game. |
LLM |
A Large Language Model is a pre-trained language model with ample knowledge about many different topics that can deliver answers in a way similar to human speach. It will be used to provide clues to the user |
Spring |
Popular framework for the development of web applications that provides different modules for common services such as authentication, access to databases, security, etc. |
Framework |
Set of concepts and practices used for solving a problem that can be used as a template for solving similar problems. |
Gemini |
A LLM developed by Google. It will be one of the LLMs used in our application. |
Gitlab flow |
Branching strategy whit 3 different branch types. A Master branch with stable code for release, a Deployment branch where errors are still being fixed and a Feature branch for each feature developed for the system. |
MongoDB |
An opensource Database system NoSQL. Since it is non-relational, the data isn’t stored in tables but in BSON, a structure similar to JSON. |
NoSQL databases |
Umbrella term used for database systems that store data in a non-relational way. In relational databases, data is stored in tables and connections are established through relationships. NoSQL databases don’t follow this format and may relate the elements of the database using any other method. |
JSON |
Text format used for transferring data. Information is stored in pairs of “name” and “value”, with “name” acting as an identifier for the attribute and “value” its current value. |
BSON |
(Binary JSON) Data format used by MongoDB. It includes all JSON data structure types and adds support for types including dates, different size integers, ObjectIds, and binary data. |
Docker |
Platform for developers and system administrators. Provides an extra layer or abstraction compared to Virtual Machines since the containers themselves are not found on the guest operating system but on Docker. It also provides orchestration between containers without the big files needed for VMs. |
Container |
Executable package that encloses an application. Multiple containers can form a complex architecture while remaining isolated from each other. It is a live instance of an image, allowing it to be shared and stored. |
Image |
File that includes everything necessary to run an application such as code, runtime system, libraries, runtime variables and configuration files. This will ensure that running the application is consistent independently of the environment. |