Repository: Arquisoft/wichat_es2c
Pull request #155: Lucas docu update
Author: login: LucasGisb
Created: 2025-04-29T12:06:42Z | Merged: 2025-05-02T22:11:09Z

My part of the documentation update done


Diff:
diff --git a/docs/images/06-chatBotFunctionality.png b/docs/images/06-chatBotFunctionality.png
new file mode 100644
index 0000000000..df243758b0
Binary files /dev/null and b/docs/images/06-chatBotFunctionality.png differ
diff --git a/docs/images/06-gameCycle.png b/docs/images/06-gameCycle.png
new file mode 100644
index 0000000000..dea249268b
Binary files /dev/null and b/docs/images/06-gameCycle.png differ
diff --git a/docs/images/06-leaderboardAndSearch.png b/docs/images/06-leaderboardAndSearch.png
new file mode 100644
index 0000000000..cab5efcc62
Binary files /dev/null and b/docs/images/06-leaderboardAndSearch.png differ
diff --git a/docs/images/06-login.png b/docs/images/06-login.png
index 6d0f40f5b6..e3b0b36411 100644
Binary files a/docs/images/06-login.png and b/docs/images/06-login.png differ
diff --git a/docs/images/06-questionGeneration.png b/docs/images/06-questionGeneration.png
new file mode 100644
index 0000000000..cc429b40e6
Binary files /dev/null and b/docs/images/06-questionGeneration.png differ
diff --git a/docs/images/06-registering.png b/docs/images/06-registering.png
index 57f609fadf..55e08eeca7 100644
Binary files a/docs/images/06-registering.png and b/docs/images/06-registering.png differ
diff --git a/docs/images/08-domainModel.png b/docs/images/08-domainModel.png
new file mode 100644
index 0000000000..94d8d4f6d2
Binary files /dev/null and b/docs/images/08-domainModel.png differ
diff --git a/docs/src/02_architecture_constraints.adoc b/docs/src/02_architecture_constraints.adoc
index f64e643da1..f82ef1c435 100644
--- a/docs/src/02_architecture_constraints.adoc
+++ b/docs/src/02_architecture_constraints.adoc
@@ -31,15 +31,21 @@ endif::arc42help[]
 
 [options="header", cols="1,1"]
 |====
-| Restriction | Explanation
+| Constraint | Explanation
 
-| Wikidata API | We will use Wikidata as the database for the places where the player can be found.
+| Deployed Web application | The application must be deployed on a server and accessible from a browser. In this case, we will use Docker to deploy it.
 
-| Deploy the application | The application must be deployed on a server and accessible from a browser. In this case, we will use Docker to deploy it.
+| Wikidata | The application will use Wikidata as it will serve as the source of the information displayed in a match's questions.
 
-| GitHub | We will use GitHub for version control and collaboration on the project.
+| LLM | The user will be able to obtain hints via a LLM Chatbot. 
+
+| Documented API | Alongside with the application, a public API will be provided, with its extensive documentation, which will provide access to users information.
 
-| Tests | The application must pass these tests to ensure its functionality; failure of any test will block deployment.
+| Data management | In order to store and manage the information regarding users and matches, it will be kept in a MongoDB database.
+
+| Tests | The application must pass a series of tests in order to ensure its functionality; failure of any test will block deployment.
+
+| GitHub | We will use GitHub for version control and collaboration on the project.
 
 | Documentation | The documentation of the entire project will be done following the Arc42 template for better clarity in its details and explanations.
 
@@ -49,7 +55,7 @@ endif::arc42help[]
 
 [options="header", cols="1,1"]
 |====
-| Restriction | Explanation
+| Constraint | Explanation
 
 | Team of 4 people | The work will be distributed among the 4 members of the group.
 
@@ -57,6 +63,17 @@ endif::arc42help[]
 
 | Issues | The work assigned to each member will be reflected as issues in GitHub, so that everything is recorded and everyone knows what they have to do.
 
+| Pull requests | In order to improve the workflow and our code consistency, every time a member is about to integrate their work into the main one, another member will review its changes via a Pull Request, requesting changes if seen as necesary.
+
 | Mid-term evaluations | Every 3 weeks the project will be checked, and corrections that need to be made for the upcoming days will be noted.
 
 |====
+
+=== Conventions
+|===
+| Constraint | Explanation
+| Arc42 | The team will follow the Arc42 template in order to structure the project documentation in a consistent and efficient way.
+| Use of English | English will be used throughout the project, including documentation, coding, and the GitHub repository, as it is the most widely accepted and understood language in the software development community.
+| Good coding practices | The team will adhere to clean code principles such as meaningful naming, modularity, simplicity, and comprehensive documentation. 
+| Branchs usage | The team will adopt a branching strategy, keeping every issue in its own branch until it is brought to master via a Pull Request.
+|===
diff --git a/docs/src/04_solution_strategy.adoc b/docs/src/04_solution_strategy.adoc
index 7f8833cf35..3c1ee7ae9c 100644
--- a/docs/src/04_solution_strategy.adoc
+++ b/docs/src/04_solution_strategy.adoc
@@ -3,31 +3,29 @@ ifndef::imagesdir[:imagesdir: ../images]
 [[section-solution-strategy]]
 == Solution Strategy
 
-=== Technologies
+=== Technological decisions
+* *JavaScript*: Primary programming language for both frontend and backend development in our project. Fit for full-stack development using a single language, reducing context switching.
 * *React*: JavaScript library for web and native user interfaces. It allows developers to create interactive web applications by breaking down the UI into reusable components. React uses a declarative approach to efficiently update and render components, resulting in faster and more maintainable code. It's widely adopted in the industry due to its simplicity, performance, and robustness.
 * *Node.js*: JavaScript runtime that enables running JavaScript code outside of web browsers. It's renowned for its event-driven architecture and extensive collection of packages, making it ideal for building scalable server-side applications.
-* *Wikidata*: Wikidata provides a REST API for retrieving information related to any topic. It helps us to dynamically generate questions for our game using it from any programming language. 
+* *Express*: Lightweight framework for Node.js used to build RESTful webs and APIs. Especially useful for the backend development and routing.
 * *MongoDB*: popular NoSQL database known for its flexibility and scalability. It stores data in flexible JSON-like documents and is widely used in modern web development for its simplicity and ability to handle large volumes of data.
+* *Wikidata*: Wikidata provides a REST API for retrieving information related to any topic. It helps us to dynamically generate questions for our game using it from any programming language. 
+* *LLM Empathy*: LLM model chosen because, in addition to already having an API key for it, it is especially easy to integrate into the application and works more than correctly to meet the needs of the Chatbot.
 * *Arc42*: framework (template) used for documenting and communicating software architectures. It provides a template for describing the architecture of a software system, covering aspects such as stakeholders, requirements, architecture decisions, components, interfaces, and quality attributes. arc42 helps teams create consistent and comprehensible architecture documentation, enabling better communication, understanding, and maintenance of software systems throughout their lifecycle.
+* *Swagger:* toolset for designing, building, documenting, and consuming RESTful web services. It allows us to automatically generate interactive API documentation, making it easier for developers to understand and test API endpoints. Swagger improves the transparency, usability, and maintenance of our backend services by ensuring clear and standardized API definitions.
 * *npm*: default package manager for Node.js, providing a command-line interface to install, manage, and publish JavaScript packages. With over a million packages available in its registry, npm simplifies adding functionality to Node.js projects by handling dependencies and providing tools for versioning and publishing packages.
+* *Oracle server*: Cloud platform used for deploying our application. The team chose Oracle Cloud Infrastructure due to prior experience with its services, which allowed for a smoother and more efficient setup. It provides a reliable environment for hosting our backend, database, and other infrastructure components, supporting scalability and high availability for the game.
 * *Docker*: platform that will be used for deploying our services inside containers. Containers are lightweight, portable, and self-sufficient units that contain everything needed to run an application, including the code, runtime, system tools, libraries, and settings. Docker enables developers to package their applications along with all dependencies into containers, ensuring consistency across different environments, such as development, testing, and production.
 * *GitHub Actions*: built-in automation tool on GitHub that allows us to automate some workflows that are triggered after some specific github branches actions at development. It provides as continuous integration of the game functionality.
 * *GitHub*: Version control and project management platform used for managing our game project. GitHub provides features for collaboration, issue tracking, and code review, facilitating efficient development workflows and team communication.
 
-
-=== Technological decisions
-
-We have decided to develop the Wikidata API in TypeScript because it is similar to JavaScript but also has static type checking.
-
 === Architecture & Design
 
-* *Microservices*: Our game is built using a microservices architecture, which structures the application as a collection of loosely coupled services. Each service encapsulates a specific functionality or business capability, allowing for independent development, deployment, and scaling. By adopting microservices, we promote modularity and flexibility, enabling rapid iteration and innovation.
-
-* *Containerization with Docker*: We leverage Docker containerization to package each microservice and its dependencies into lightweight, portable containers. Docker provides a consistent environment across different stages of the development lifecycle, ensuring seamless deployment and scalability. With Docker, we can easily spin up new instances of services, manage dependencies, and streamline our development and deployment workflows.
+* *Services based project*: Although not a full microservices architecture, our project is designed in a modular and service-oriented way. Each major functionality is isolated into separate logical units or services that can be developed and maintained independently. This enhances flexibility and maintainability without the complexity of full microservice infrastructure.
 
-* *API Gateway*: We employ an API gateway as a centralized entry point for all client requests to our microservices. The API gateway serves as a reverse proxy, routing incoming requests to the appropriate microservice based on predefined rules and policies. It provides a unified interface for clients to interact with our system, abstracting away the complexities of the underlying microservices architecture. By consolidating access through the API gateway, we enhance security, governance, and performance while simplifying client interactions.
+* *Containerization with Docker*: We leverage Docker containerization to package each service and its dependencies into lightweight, portable containers. Docker provides a consistent environment across different stages of the development lifecycle, ensuring seamless deployment and scalability. With Docker, we can easily spin up new instances of services, manage dependencies, and streamline our development and deployment workflows.
 
-* *Scalability and Elasticity*: With our microservices architecture orchestrated with Docker, we achieve horizontal scalability and elasticity to handle fluctuations in traffic and workload. Docker's container-based approach enables us to dynamically scale individual services based on demand, ensuring optimal resource utilization and cost efficiency. Combined with automated scaling policies and monitoring, we maintain responsiveness and availability during peak usage periods.
+* *API Gateway*: We employ an API gateway as a centralized entry point for all client requests to our services. The API gateway serves as a reverse proxy, routing incoming requests to the appropriate service based on predefined rules and policies. It provides a unified interface for clients, abstracting the complexity of the underlying system and improving performance, scalability, and security.
 
 
 === Team Organization
@@ -38,7 +36,7 @@ The master branch contains the final version of the product, so that every accep
 * *Documentation*: it must be always updated for making our work valuable and consistent.
 * *Weekly meetings*: Weekly discussions about what has been done and what needs to be done will be key for our team success. 
 * *Github*: this control version systems not only allows us to share and collabortively write code, but also provides other resources such as issues and project management (kanban board) tools for organizing the work to be done. Also, wiki section allows us to save all of our minutes from each scheduled meeting.
-* *Whatsapp and Discord*: will allow us to be in constant communication for helping each other out whenever needed. 
+* *Whatsapp and Discord*: Allow us to be in constant communication for helping each other out whenever needed. 
 
 ifdef::arc42help[]
 [role="arc42help"]
diff --git a/docs/src/06_runtime_view.adoc b/docs/src/06_runtime_view.adoc
index 0f5c6d021c..841ab361a1 100644
--- a/docs/src/06_runtime_view.adoc
+++ b/docs/src/06_runtime_view.adoc
@@ -22,10 +22,40 @@ image:06-login.png["Runtime view - Logging in"]
 
 When it comes to logging in, the user firstly enters their credentials, then the back end retrieves the user's information from the database and verifies if it's correct.
 
-=== Future diagrams
 
-Once we have made progress in the development of the application, the following diagrams should be created according to the chosen implementation:
+=== Questions generation
+&nbsp;
+
+image:06-questionGeneration.png["Runtime view - Question generation"]
+
+&nbsp;
+
+The user accesses the game, selects its mode and difficulty, and the call is made. The backend is responsible for obtaining the questions (along with their images and answers) and transmitting them to the frontend.
+
+=== WiChat quiz game
+&nbsp;
+
+image:06-gameCycle.png["Runtime view - Game cycle"]
+
+&nbsp;
+
+
+The user enters the game, selects the mode and difficulty, and once the question is answered, the user begins the game, answering each question until the timer runs out, ending the game. After the game ends, and after the information has been saved, the user can replay the game or access other views.
+
+=== Obtaining hints via Chatbot
+&nbsp;
+
+image:06-chatBotFunctionality.png["Runtime view - Hints by chatbot"]
+
+&nbsp;
+
+In the Game view, the user types their questions into the Chatbot component, which are then sent to the LLM, where the prompt to be passed to the AI ​​is configured and the response is generated, which is then returned to the frontend for the user to view.
+
+=== Leaderboard and match search
+&nbsp;
+
+image:06-leaderboardAndSearch.png["Runtime view - Leaderboard and match search"]
+
+&nbsp;
 
-==== Questions generation
-==== WiChat quiz game
-==== Obtaining hints via Chatbot
+When the user accesses the Leaderboard, the system loads ranking and user data, while also allowing the user to search for specific user's games by entering its name in the search bar.
diff --git a/docs/src/08_concepts.adoc b/docs/src/08_concepts.adoc
index 773e643347..a2ab694801 100644
--- a/docs/src/08_concepts.adoc
+++ b/docs/src/08_concepts.adoc
@@ -57,47 +57,69 @@ See https://docs.arc42.org/section-8/[Concepts] in the arc42 documentation.
 ****
 endif::arc42help[]
 
-=== _Continuous integration and development_
+=== _Domain concepts_
 
+|===
+| *Class* | *Explanation*
+| User | The people using the application, playing matches and generating statistics of their own.
+| Statistics | Given the performance of the player in its matches, relevant information is stored.
+| Match | Created when the user starts a game and includes its general information and generated questions.
+| Question | Questions spawned in a match, storing all its answers.
+| Answer | Every answer associated to a match's question, saving if it was the correct option and if was selected by the player.
+|===
+image:08-domainModel.png["Concepts - Domain Model"]
+
+
+=== _"Under-the-hood"_
+
+* *Backend*:  
+  The server-side logic of the application is implemented using Node.js in combination with the Express framework. The backend handles client requests, communicates with external services such as Wikidata and Empathy, manages user sessions, interacts with the database and other functionalities.
+
+* *Frontend*:  
+  The frontend is developed using React, a component-based JavaScript library that enables the creation of dynamic and interactive user interfaces. The frontend is responsible for rendering the game interface, managing user input, and presenting questions, hints, and scores.
+
+* *Database and persistence*:  
+  MongoDB serves as the main data store, offering a flexible document-oriented model that aligns well with the evolving structure of game data. It stores user profiles, game progress, generated questions, and historical results in JSON-like documents.
+
+* *LLM Integration*:  
+  We utilize Empathy, a Large Language Model (LLM), to enhance the gameplay experience by generating intelligent and context-aware hints for each question in real time.
+
+* *External Data Source*:  
+  To keep the game content rich and dynamic, we integrate Wikidata as our primary external knowledge source. Through its public REST API, we query up-to-date and structured information about a wide range of topics. This enables automatic generation of questions based on real-world data.
+
+
+
+=== _Development concepts_
+* *Continuous integration and development*
 Our way of working with github is having one developing branch towards which all pull requests are done 
 and have to be reviewed by at least one team member. 
 Sonar Cloud is set up so we know the testing coverage and whether we pass the quality gate with every pull request.
 Once there is enough change in the develop branch with respect to the main one and it has enough quality we can 
 merge them and make a release.
 
+* *Testings*
+One of the most important aspects is testing our application, and to achieve this, we will conduct different types of tests. On one hand, we will perform tests such as unit testing and usability testing. On the other hand, we will implement a continuous testing system using GitHub Actions, ensuring that all commits pass the required tests.
 
-=== _Microservice based system_
-
-Different business functionallities will be developed in different independent services.
-This will ensure that if one of them fails, the rest are still working (For example,
-if the rankings go down that will not affect the main game) as they have their own deployment
-as well. 
-Other benefits are increased maintainability due to separation in small, more readable modules
-and the possibillity of using different languages or technologies for each module if needed/prefered 
-without colliding with the rest.
+* *Docker*
+Docker is used to ensure consistent environments across development, testing, and deployment. By containerizing the application, we can avoid issues related to local setup differences and dependency mismatches.
 
+* *GitHub Actions*
+GitHub Actions is integrated into our repository to automate key parts of the development lifecycle. We use it for continuous integration (CI), running automated tests on every push or pull request, and checking code quality with SonarCloud. Additionally, it supports continuous deployment workflows by enabling the automatic building and deployment of Docker containers when changes are merged into the main branch.
 
-=== _Gateway service routing_
 
+=== _Operational concepts_
+* *Gateway service routing*
 We will use a speciallized service that will route the requests to the corresponding service, acting as 
 a single entry point for the application. Requests to the services are much simpler as only the api base 
 endpoint and the action needs to be known and the gateway can also act as a filter to manage requests 
 conditionally if needed. This approach also favors security as we can control which requests are actually 
 sent based on its content or the context of the app.
 
-=== _Authentication_
-
-To keep our users' data secure an authentication mechanism has been developed with the use of JSON Web Tokens (JWT). If someone tries to access historical game records for certain users, our KaW application enforces to pass a valid token through the header of the message request.
-In this way, only authenticated users are able to consult the different data that our application enforces.
+=== _Safety and security concepts_
 
-=== _Internationalization_ 
+* *Secure storage*
+User passwords are never stored in plain text. Instead, secure hashing algorithms and encryption techniques are employed to protect sensitive information and prevent unauthorized access.
 
-One of the things to increase accessibility is giving our application the capability of being in various languages so people around the world can play our game. Obviously, internationalization is more than just changing the language of the Application but due to time constraints we will just offer Spanish, English, Ukrainian and French languages ( although, our API can generate questions in other languages different from described, to see the whole list, refer to our API documentation ).
+*Security redirections* 
+The app redirects you to the login page if you try to access features that requires you to be logged while you are not.
 
-The library used for language translation in our KaW game is called react-i18next. For simplicity (and due to just only having three languages), all of the translations of messages are stored locally in properties files. Eventually, if the Application grows and we wanted to have more than 4 languages the best approach is to store those properties in a server and let the application to request those on the fly. Again, for simplicity the option of having all bundle together in the Frontend just fits.
-
-The translation of questions is a bit different from the frontend part since it is done "on the fly" by using the Microsoft translation API . This change has been done since the questions are not fully known until they are generated so storing the translation locally does not provide any benefit. Also, one advantage of it, is its simplicity and ease to use. To meet the restrictions impose by the Free version of this API a series of formatting rules are carried out into the question generation phase to minimize the usage of it and avoid getting suspended.
-
-=== _Tests_
-
-One of the most important aspects is testing our application, and to achieve this, we will conduct different types of tests. On one hand, we will perform tests such as unit testing and usability testing. On the other hand, we will implement a continuous testing system using GitHub Actions, ensuring that all commits pass the required tests.
diff --git a/docs/src/09_architecture_decisions.adoc b/docs/src/09_architecture_decisions.adoc
index 22f450c677..4a5c9ac39f 100644
--- a/docs/src/09_architecture_decisions.adoc
+++ b/docs/src/09_architecture_decisions.adoc
@@ -1,44 +1,435 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Database:* MongoDB (see <<ADR-002>>)
+* *Deployment:* Docker
+
+==== Reasoning
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Reasoning
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+* Better integration with JSON than other alternatives like SQL.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+  ** Wasn't integrated on the initial project.
+
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+*Status: Proposed and Rejected*
+*:date: 16/03/2025* 
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Reasoning
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript. JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+*Status: Accepted*
+*:date: 16/03/2025* 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Reasoning
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle Cloud VM for Deployment Infrastructure
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+The application required a virtualized environment to deploy the frontend, backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and having almost every member of the team some level of experince, thanks to having used it in other subjects.
+
+However, during early planning, one team member already had access to an Oracle Cloud VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle Cloud VM instance to host the project infrastructure.
+
+==== Reasoning
+
+* Immediate availability of an Oracle Cloud VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+* With Oracle Cloud VM we can have the aplicattion deployed 24/7.
+* In case anyone have to do any kind of work on the VM, giving access to it is simple because only SSH key and the IP are required.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+  *** In case we have used Azure, we would be obligated to turn on and off the application whenever it is necessary.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost during the development.
+* May require future migration or scaling strategy if the project grows or if Oracle Cloud VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed and followed due to its popularity and the main project was built in a microservice based architecture.
+However, during the development of the application, a service-based architecture was chosen instead.
+
+==== Decision
+
+The project adopts a service-based architecture, rather than a fully decoupled microservices model.
+
+==== Reasoning
+
+* Provides modularization and separation of concerns without the overhead of managing independent deployments for each service.
+* Simplifies inter-service communication by avoiding complex patterns such as service discovery, load balancing, and distributed configuration.
+* Better aligns with the existing project base and team size, facilitating easier maintenance and deployment.
+* Reduces initial development and operational complexity.
+
+==== Alternatives considered
+
+*Pure Microservices Architecture*
+
+** Pros:
+  *** Strong decoupling, allowing for independent scaling and deployment of services.
+** Cons:
+  *** Overkill for small or medium-sized teams and projects with limited domain boundaries.
+
+==== Consequences
+
+* Enables a modular structure where services are separated logically but may coexist within the application itself.
+* Facilitates faster development and easier testing given its monolithichal nature with less enviroment complexity.
+* Allows future evolution toward microservices if project requirements grow.
+
+
+
+[[ADR-007]]
+=== ADR 007: Data Storage for Wikidata Information
+*Status: Accepted*
+*:date: 16/03/2025* 
+
+==== Context
+
+Initially, the application fetched data from Wikidata in real time during gameplay to generate questions dynamically.
+However, this approach caused severe performance issues, resulting in noticeable delays that degraded the user experience during matches.
+
+==== Decision
+
+To improve performance, the application now pre-generates and stores a set of questions in the database at the start of each game.
+These stored questions are then served to the user dynamically throughout the match, minimizing latency.
+
+==== Reasoning
+
+* Real-time queries to Wikidata introduced unpredictable delays and negatively impacted gameplay flow.
+* Preloading questions ensures smooth and uninterrupted user experience.
+* Reduces dependency on external services during active sessions, making the game more stable and reliable.
+
+==== Alternatives considered
+
+*Inserting loading screens between questions*
+
+** Pros:
+  *** Would allow real-time querying to continue without significant architectural changes.
+  *** Could be visually appealing with the right UI/UX design.
+** Cons:
+  *** Did not solve the root performance issue — only masked it.
+  *** Introduced unwanted pauses that disrupted the game's pacing and fluidity.
+
+==== Consequences
+
+* Game sessions begin with a brief setup phase where questions are fetched and stored.
+* Once the session starts, question delivery is fast and reliable, improving overall experience.
+* The system is now more resilient to outages or slowdowns in the Wikidata SPARQL endpoint.
+
+
+
+[[ADR-008]]
+=== ADR 008: Styling Approach - CSS Modules
+*Status: Accepted*
+*:date: 16/03/2025* 
+
+==== Context
+
+Maintaining scoped styles without introducing unnecessary complexity.
+
+==== Decision
+
+Use CSS Modules for styling, with partial hybridization where needed.
+
+==== Reasoning
+
+* Keeps styles encapsulated.
+* Allows flexibility where global styles are needed.
+
+==== Consequences
+
+* Mixed styling approach may introduce slight overhead.
+
+
+[[ADR-009]]
+=== ADR 009: Choice and Strategy for Empathy LLM Models
+*Status: Accepted*
+*:date: 07/04/2025* 
+
+==== Context
+
+To implement the chatbot system that provides hints during gameplay, the project required integration with a Large Language Model (LLM). The goal was to offer accurate, responsive, and trustworthy hints, as this directly affects the player's experience and engagement.
+
+Initially, the team selected the **Qwen2.5-Coder-7B-Instruct** model from the Empathy LLM platform given he had access thanks to the API Key provided to us. However, as development progressed, it became apparent that system outages or instability in the LLM provider could render the chatbot feature temporarily unusable — severely impacting reliability.
+
+==== Decision
+
+We implemented a dual-model system using both **Qwen2.5-Coder-7B-Instruct** and **Mistral-7B-Instruct-v0.3**, both available through Empathy LLM. The application now automatically switches between the two models depending on their availability, ensuring continued service during partial outages.
+
+==== Reasoning
+
+* Qwen2.5-Coder-7B-Instruct was initially chosen as it shown less tendency to cause hallucinations.
+* However, Qwen showed higher sensitivity to downtime and occasional availability issues during use.
+* Mistral-7B-Instruct-v0.3, while slightly more verbose, provided reliable backup behavior and acceptable quality.
+* The switch-over mechanism improves fault tolerance without significantly degrading response quality.
+
+==== Alternatives considered
+
+*Switch entirely to Mistral*
+
+** Pros:
+  *** More stable availability during testing.
+** Cons:
+  *** Lower quality in guided, instructional prompts; less aligned with user needs.
+  *** Returning to a single-model setup would reintroduce the same availability risks — if Mistral fails, the chatbot would again become unusable.
+
+==== Consequences
+
+* Improved resilience and availability of the chatbot feature.
+* Slight variability in hint style depending on the model currently active.
+* Additional complexity added to the backend logic to monitor model health and manage fallback behavior.
+* Future work could include evaluating additional models or services to further enhance reliability and output quality.
+
+
+
+
+=== ADR 010: Monitoring Strategy
+*Status: Accepted*
+*:date: 07/04/2025* 
+
+==== Context
+
+The application required a monitoring solution to track performance metrics, usage, and system health. Since the deployment is hosted on Oracle Cloud VM, Oracle Cloud Monitoring was initially considered as a natural choice due to existing familiarity and integration.
+
+However, Prometheus and Grafana were already configured in the environment, and their open-source flexibility and ecosystem made them a strong alternative.
+
+==== Decision
+
+The team chose to implement application monitoring using Prometheus for data collection and Grafana for visualization.
+
+==== Reasoning
+
+* Prometheus and Grafana were already partially configured and tested.
+* Broad community support and extensive documentation.
+* Easier to integrate with a variety of services and custom metrics.
+* Enables flexible dashboards and alerting rules tailored to the application’s needs.
+
+==== Alternatives considered
+
+*Oracle Cloud Monitoring*
+
+** Pros:
+  *** Native to Oracle Cloud VM.
+  *** Familiar interface for some team members.
+  *** Integrated with Oracle’s infrastructure metrics and logging.
+** Cons:
+  *** Less customizable for application-specific metrics.
+  *** More limited in community resources and ecosystem tools.
+  *** Requires additional setup to match the flexibility offered by Prometheus/Grafana.
+
+==== Consequences
+
+* Monitoring is decoupled from Oracle Cloud, making it more portable.
+* Dashboards and alerts can be easily customized and extended.
+
+
+=== ADR 011: DNS and Reverse Proxy Setup
+*Status: Accepted*
+*:date: 30/04/2025* 
 
-The service in charge of comunicating with WikiData will be coded using TypeSript. 
-As the generation of questions is a huge part of our application we will play it safe by using TypeSript, a language that is similar to JavaSript but with static type checking.
+==== Context
 
-*03/02/2025*
+To allow users and services to access the deployed application on Oracle Cloud VM via a friendly domain and standard HTTP port, a DNS and reverse proxy solution was needed. The goal was to expose the service at a clean URL (`http://wic2c.duckdns.org`) instead of a raw IP address with a non-standard port.
 
-Microservices Architecture:
-The application will follow a Microservices architecture to ensure scalability, flexibility, and easier maintenance. This approach allows different services to be developed, deployed, and scaled independently, improving fault tolerance and facilitating continuous deployment.
+==== Decision
 
-WikiData Service - TypeScript:
-The service responsible for communicating with WikiData will be developed using TypeScript. Since generating questions is a critical part of our application, we decided to use TypeScript due to its static type checking, which helps prevent runtime errors and makes the codebase more maintainable. Additionally, TypeScript provides better tooling support and improves developer productivity by reducing debugging time.
+The team chose to use **DuckDNS** as a free DNS provider and **Nginx** as a reverse proxy.
 
-Backend & Frontend Technologies:
-The backend will be built using Node.js, as it is efficient for handling asynchronous operations and provides a vast ecosystem of libraries.
-The frontend will be developed with React, a popular JavaScript library known for its component-based structure, performance optimizations, and reusability. React's virtual DOM improves rendering efficiency, making it a great choice for dynamic applications.
+==== Reasoning
 
-Database - MongoDB:
-We have chosen MongoDB, a NoSQL database, because it provides flexibility in handling unstructured data, horizontal scalability, and high availability. Given that our data structure may evolve over time, MongoDB’s schema-less nature allows us to adapt without complex migrations.
+* **DuckDNS**:
+  ** Free and simple dynamic DNS service.
+  ** Allows mapping a custom subdomain (`wic2c.duckdns.org`) to the public IP address of the Oracle VM.
+  ** No cost, no registration complexity.
+* **Nginx**:
+  ** Acts as a reverse proxy, listening on port `80`.
+  ** Redirects traffic internally to port `3000`, where the application or monitoring stack is hosted.
+  ** Enables clean, production-like access to services without exposing internal port numbers.
 
-Deployment Strategy:
-The application will be deployed on a server owned by one of the team members. This decision allows us to have full control over the deployment environment, reduce costs, and customize configurations based on our needs.
+==== Alternatives considered
 
-*03/03/2025*
+*Using only raw IP and ports*
 
-Switching from TypeScript to JavaScript:
-We initially opted for TypeScript to improve code quality through static typing. However, after encountering integration issues, increased complexity, and longer development time, we decided to switch to JavaScript. JavaScript allows for faster iteration, broader community support, and reduced setup overhead, making it more practical for our project timeline.
+** Pros:
+  *** No need to configure DNS or proxy layers.
+  *** Slightly faster setup.
+** Cons:
+  *** Users would need to remember IP addresses and ports (e.g., `http://123.45.67.89:3000`).
+  *** Less professional appearance.
+  *** Harder to manage and scale in future.
 
-CSS Modules for Styling:
-We have chosen to use CSS Modules for styling because it:
+==== Consequences
 
-Prevents style conflicts by scoping styles to individual components.
-Improves maintainability by keeping styles modular and easy to manage.
-Enhances reusability as styles are encapsulated within their respective components, reducing the risk of unintended global overrides.
+* Users and developers can access the application at `http://wic2c.duckdns.org` using standard web protocols.
+* Internal routing and ports remain abstracted, improving security and maintainability.
+* Future enhancements (e.g., HTTPS, load balancing) can be layered onto the Nginx configuration.
+* Reliance on DuckDNS introduces a small risk of service availability tied to a free third-party provider.
 
-These decisions were made to optimize performance, maintainability, and scalability while ensuring smooth development and deployment of our application.
 
 
 [role="arc42help"]


Reviews:
user: login: ElPandaP
state: CHANGES_REQUESTED
author_association: NONE
submitted_at: 2025-04-29T17:59:37Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T17:43:12Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T17:45:03Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T17:46:00Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T17:46:30Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T17:49:01Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T17:51:47Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T17:53:32Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T17:53:48Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T17:53:58Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T17:54:14Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T17:54:36Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T17:55:35Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T17:55:44Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T17:56:30Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T17:56:41Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T17:58:22Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T17:58:36Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T18:00:19Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T18:00:32Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T18:00:43Z
user: login: ElPandaP
state: CHANGES_REQUESTED
author_association: NONE
submitted_at: 2025-05-02T04:08:39Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-02T20:33:17Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-02T20:36:09Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-02T20:42:02Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-02T20:47:51Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-02T20:50:13Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-02T20:51:05Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-02T20:56:12Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-02T20:56:43Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-02T20:56:56Z
user: login: LucasGisb
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-02T21:00:33Z
user: login: ElPandaP
state: APPROVED
author_association: NONE
submitted_at: 2025-05-02T22:10:33Z

Review comments:
diff_hunk: @@ -22,10 +22,40 @@ image:06-login.png["Runtime view - Logging in"]
 
 When it comes to logging in, the user firstly enters their credentials, then the back end retrieves the user's information from the database and verifies if it's correct.
 
-=== Future diagrams
 
-Once we have made progress in the development of the application, the following diagrams should be created according to the chosen implementation:
+=== Questions generation
+&nbsp;
+
+image:06-questionGeneration.png["Runtime view - Question generation"]
path: docs/src/06_runtime_view.adoc
user: login: ElPandaP
body: change Game to webapp or Game.jsx
created_at: 2025-04-29T16:28:47Z
author_association: NONE
diff_hunk: @@ -22,10 +22,40 @@ image:06-login.png["Runtime view - Logging in"]
 
 When it comes to logging in, the user firstly enters their credentials, then the back end retrieves the user's information from the database and verifies if it's correct.
 
-=== Future diagrams
 
-Once we have made progress in the development of the application, the following diagrams should be created according to the chosen implementation:
+=== Questions generation
+&nbsp;
+
+image:06-questionGeneration.png["Runtime view - Question generation"]
+
+&nbsp;
+
+The user accesses the game, selects its mode and difficulty, and the call is made. The backend is responsible for obtaining the questions (along with their images and answers) and transmitting them to the frontend.
+
+=== WiChat quiz game
+&nbsp;
+
+image:06-gameCycle.png["Runtime view - Game cycle"]
path: docs/src/06_runtime_view.adoc
user: login: ElPandaP
body: webapp doesn't communicate with wikidata or game service, only with the gateway
created_at: 2025-04-29T16:30:18Z
author_association: NONE
diff_hunk: @@ -22,10 +22,40 @@ image:06-login.png["Runtime view - Logging in"]
 
 When it comes to logging in, the user firstly enters their credentials, then the back end retrieves the user's information from the database and verifies if it's correct.
 
-=== Future diagrams
 
-Once we have made progress in the development of the application, the following diagrams should be created according to the chosen implementation:
+=== Questions generation
+&nbsp;
+
+image:06-questionGeneration.png["Runtime view - Question generation"]
+
+&nbsp;
+
+The user accesses the game, selects its mode and difficulty, and the call is made. The backend is responsible for obtaining the questions (along with their images and answers) and transmitting them to the frontend.
+
+=== WiChat quiz game
+&nbsp;
+
+image:06-gameCycle.png["Runtime view - Game cycle"]
+
+&nbsp;
+
+
+The user enters the game, selects the mode and difficulty, and once the question is answered, the user begins the game, answering each question until the timer runs out, ending the game. After the game ends, and after the information has been saved, the user can replay the game or access other views.
+
+=== Obtaining hints via Chatbot
+&nbsp;
+
+image:06-chatBotFunctionality.png["Runtime view - Hints by chatbot"]
path: docs/src/06_runtime_view.adoc
user: login: ElPandaP
body: Put chatbot.jsx and game.jsx so that it's clear that game doesn't refer to the game service
created_at: 2025-04-29T16:31:37Z
author_association: NONE
diff_hunk: @@ -22,10 +22,40 @@ image:06-login.png["Runtime view - Logging in"]
 
 When it comes to logging in, the user firstly enters their credentials, then the back end retrieves the user's information from the database and verifies if it's correct.
 
-=== Future diagrams
 
-Once we have made progress in the development of the application, the following diagrams should be created according to the chosen implementation:
+=== Questions generation
+&nbsp;
+
+image:06-questionGeneration.png["Runtime view - Question generation"]
+
+&nbsp;
+
+The user accesses the game, selects its mode and difficulty, and the call is made. The backend is responsible for obtaining the questions (along with their images and answers) and transmitting them to the frontend.
+
+=== WiChat quiz game
+&nbsp;
+
+image:06-gameCycle.png["Runtime view - Game cycle"]
path: docs/src/06_runtime_view.adoc
user: login: ElPandaP
body: also if you write about the llm api in the next diagram, you may as well write about the wikidata api in this one
created_at: 2025-04-29T16:32:52Z
author_association: NONE
diff_hunk: @@ -22,10 +22,40 @@ image:06-login.png["Runtime view - Logging in"]
 
 When it comes to logging in, the user firstly enters their credentials, then the back end retrieves the user's information from the database and verifies if it's correct.
 
-=== Future diagrams
 
-Once we have made progress in the development of the application, the following diagrams should be created according to the chosen implementation:
+=== Questions generation
+&nbsp;
+
+image:06-questionGeneration.png["Runtime view - Question generation"]
+
+&nbsp;
+
+The user accesses the game, selects its mode and difficulty, and the call is made. The backend is responsible for obtaining the questions (along with their images and answers) and transmitting them to the frontend.
+
+=== WiChat quiz game
+&nbsp;
+
+image:06-gameCycle.png["Runtime view - Game cycle"]
+
+&nbsp;
+
+
+The user enters the game, selects the mode and difficulty, and once the question is answered, the user begins the game, answering each question until the timer runs out, ending the game. After the game ends, and after the information has been saved, the user can replay the game or access other views.
+
+=== Obtaining hints via Chatbot
+&nbsp;
+
+image:06-chatBotFunctionality.png["Runtime view - Hints by chatbot"]
+
+&nbsp;
+
+In the Game view, the user types their questions into the Chatbot component, which are then sent to the LLM, where the prompt to be passed to the AI ​​is configured and the response is generated, which is then returned to the frontend for the user to view.
+
+=== Leaderboard and match search
+&nbsp;
+
+image:06-leaderboardAndSearch.png["Runtime view - Leaderboard and match search"]
path: docs/src/06_runtime_view.adoc
user: login: ElPandaP
body: Put mongodb communication
created_at: 2025-04-29T16:34:36Z
author_association: NONE
diff_hunk: @@ -57,47 +57,62 @@ See https://docs.arc42.org/section-8/[Concepts] in the arc42 documentation.
 ****
 endif::arc42help[]
 
-=== _Continuous integration and development_
+=== _Domain concepts_
 
+|===
+| *Class* | *Explanation*
+| User | The people using the application, playing matches and generating statistics of their own.
+| Statistics | Given the performance of the player in its matches, relevant information is stored.
+| Match | Created when the user starts a game and includes its general information and generated questions.
+| Question | Questions spawned in a match, storing all its answers.
+| Answer | Every answer associated to a match's question, saving if it was the correct option and if was selected by the player.
+|===
+image:08-domainModel.png["Concepts - Domain Model"]
+
+
+=== _"Under-the-hood"_
+
+* *Backend*:  
+  The server-side logic of the application is implemented using Node.js in combination with the Express framework. The backend handles client requests, communicates with external services such as Wikidata and Gemini, manages user sessions, interacts with the database and other functionalities.
+
+* *Frontend*:  
+  The frontend is developed using React, a component-based JavaScript library that enables the creation of dynamic and interactive user interfaces. The frontend is responsible for rendering the game interface, managing user input, and presenting questions, hints, and scores.
+
+* *Database and persistence*:  
+  MongoDB serves as the main data store, offering a flexible document-oriented model that aligns well with the evolving structure of game data. It stores user profiles, game progress, generated questions, and historical results in JSON-like documents.
+
+* *LLM Integration*:  
+  We utilize Gemini, a Large Language Model (LLM), to enhance the gameplay experience by generating intelligent and context-aware hints for each question in real time.
+
+* *External Data Source*:  
+  To keep the game content rich and dynamic, we integrate Wikidata as our primary external knowledge source. Through its public REST API, we query up-to-date and structured information about a wide range of topics. This enables automatic generation of questions based on real-world data.
+
+
+
+=== _Development concepts_
+* *Continuous integration and development*
 Our way of working with github is having one developing branch towards which all pull requests are done 
 and have to be reviewed by at least one team member. 
 Sonar Cloud is set up so we know the testing coverage and whether we pass the quality gate with every pull request.
 Once there is enough change in the develop branch with respect to the main one and it has enough quality we can 
 merge them and make a release.
 
+* *Testings*
+One of the most important aspects is testing our application, and to achieve this, we will conduct different types of tests. On one hand, we will perform tests such as unit testing and usability testing. On the other hand, we will implement a continuous testing system using GitHub Actions, ensuring that all commits pass the required tests.
 
-=== _Microservice based system_
-
-Different business functionallities will be developed in different independent services.
-This will ensure that if one of them fails, the rest are still working (For example,
-if the rankings go down that will not affect the main game) as they have their own deployment
-as well. 
-Other benefits are increased maintainability due to separation in small, more readable modules
-and the possibillity of using different languages or technologies for each module if needed/prefered 
-without colliding with the rest.
-
-
-=== _Gateway service routing_
-
+=== _Operational concepts_
+* *Gateway service routing*
 We will use a speciallized service that will route the requests to the corresponding service, acting as 
 a single entry point for the application. Requests to the services are much simpler as only the api base 
 endpoint and the action needs to be known and the gateway can also act as a filter to manage requests 
 conditionally if needed. This approach also favors security as we can control which requests are actually 
 sent based on its content or the context of the app.
 
-=== _Authentication_
-
+=== _Safety and security concepts_
+* *Authentication*
 To keep our users' data secure an authentication mechanism has been developed with the use of JSON Web Tokens (JWT). If someone tries to access historical game records for certain users, our KaW application enforces to pass a valid token through the header of the message request.
path: docs/src/08_concepts.adoc
user: login: ElPandaP
body: We don't do that
created_at: 2025-04-29T16:43:14Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: why bullet points?
created_at: 2025-04-29T17:14:28Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: it wasn't already integrated in the project
created_at: 2025-04-29T17:15:26Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: mongodb should also be here
created_at: 2025-04-29T17:16:32Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: frontend is also deployed there
created_at: 2025-04-29T17:24:44Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: Oracle cloud VM
created_at: 2025-04-29T17:25:00Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: And I would delete the "enterprise-grade features" and write about that all the integrants of the team had already worked with Azure in other subjects
created_at: 2025-04-29T17:28:04Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: Write about that if we use Azure we would have to turn it on and off while in Oracle it's up 24/7
created_at: 2025-04-29T17:31:02Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: Also because of that if someone needs to work on the machine he would need access to the microsoft account while in Oracle he would only need the SSH key and host ip
created_at: 2025-04-29T17:32:40Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: In early development? It's through all the development. Or only the ending one since we hadn't the app deployed on the vm since the start
created_at: 2025-04-29T17:34:41Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
+* May require future migration or scaling strategy if the project grows or if Oracle VM limitations become restrictive.
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: This applies to all the vm hosting sites
created_at: 2025-04-29T17:35:47Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
+* May require future migration or scaling strategy if the project grows or if Oracle VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+:status: Accepted
+:date: 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed due to its popularity and alignment with distributed systems.
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: Mention that the main project was built to be a microservices one
created_at: 2025-04-29T17:37:01Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
+* May require future migration or scaling strategy if the project grows or if Oracle VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+:status: Accepted
+:date: 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed due to its popularity and alignment with distributed systems.
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: Also you should mention that initially we started as a microservice project but it growed into a service one due to some interconnections between services and having only one database
created_at: 2025-04-29T17:38:07Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
+* May require future migration or scaling strategy if the project grows or if Oracle VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+:status: Accepted
+:date: 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed due to its popularity and alignment with distributed systems.
+However, after evaluating the complexity and actual needs of the project, a service-based architecture was chosen instead.
+
+==== Decision
+
+The project adopts a service-based architecture, rather than a fully decoupled microservices model.
+
+==== Rationale
+
+* Provides modularization and separation of concerns without the overhead of managing independent deployments for each service.
+* Simplifies inter-service communication by avoiding complex patterns such as service discovery, load balancing, and distributed configuration.
+* Better aligns with the existing project base and team size, facilitating easier maintenance and deployment.
+* Reduces initial development and operational complexity.
+
+==== Alternatives considered
+
+*Pure Microservices Architecture*
+
+** Pros:
+  *** Strong decoupling, allowing for independent scaling and deployment of services.
+  *** Improved fault isolation and technology diversity.
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: Why technology diversity
created_at: 2025-04-29T17:50:14Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
+* May require future migration or scaling strategy if the project grows or if Oracle VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+:status: Accepted
+:date: 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed due to its popularity and alignment with distributed systems.
+However, after evaluating the complexity and actual needs of the project, a service-based architecture was chosen instead.
+
+==== Decision
+
+The project adopts a service-based architecture, rather than a fully decoupled microservices model.
+
+==== Rationale
+
+* Provides modularization and separation of concerns without the overhead of managing independent deployments for each service.
+* Simplifies inter-service communication by avoiding complex patterns such as service discovery, load balancing, and distributed configuration.
+* Better aligns with the existing project base and team size, facilitating easier maintenance and deployment.
+* Reduces initial development and operational complexity.
+
+==== Alternatives considered
+
+*Pure Microservices Architecture*
+
+** Pros:
+  *** Strong decoupling, allowing for independent scaling and deployment of services.
+  *** Improved fault isolation and technology diversity.
+** Cons:
+  *** High operational complexity (e.g., service orchestration, distributed logging, network latency).
+  *** Requires significant infrastructure (service registry, message brokers, etc.).
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: Doesn't apply to our project
created_at: 2025-04-29T17:53:12Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
+* May require future migration or scaling strategy if the project grows or if Oracle VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+:status: Accepted
+:date: 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed due to its popularity and alignment with distributed systems.
+However, after evaluating the complexity and actual needs of the project, a service-based architecture was chosen instead.
+
+==== Decision
+
+The project adopts a service-based architecture, rather than a fully decoupled microservices model.
+
+==== Rationale
+
+* Provides modularization and separation of concerns without the overhead of managing independent deployments for each service.
+* Simplifies inter-service communication by avoiding complex patterns such as service discovery, load balancing, and distributed configuration.
+* Better aligns with the existing project base and team size, facilitating easier maintenance and deployment.
+* Reduces initial development and operational complexity.
+
+==== Alternatives considered
+
+*Pure Microservices Architecture*
+
+** Pros:
+  *** Strong decoupling, allowing for independent scaling and deployment of services.
+  *** Improved fault isolation and technology diversity.
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: Doesn't apply to our project
created_at: 2025-04-29T17:53:28Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
+* May require future migration or scaling strategy if the project grows or if Oracle VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+:status: Accepted
+:date: 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed due to its popularity and alignment with distributed systems.
+However, after evaluating the complexity and actual needs of the project, a service-based architecture was chosen instead.
+
+==== Decision
+
+The project adopts a service-based architecture, rather than a fully decoupled microservices model.
+
+==== Rationale
+
+* Provides modularization and separation of concerns without the overhead of managing independent deployments for each service.
+* Simplifies inter-service communication by avoiding complex patterns such as service discovery, load balancing, and distributed configuration.
+* Better aligns with the existing project base and team size, facilitating easier maintenance and deployment.
+* Reduces initial development and operational complexity.
+
+==== Alternatives considered
+
+*Pure Microservices Architecture*
+
+** Pros:
+  *** Strong decoupling, allowing for independent scaling and deployment of services.
+  *** Improved fault isolation and technology diversity.
+** Cons:
+  *** High operational complexity (e.g., service orchestration, distributed logging, network latency).
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: change the ejemples for "for administrating multiple databses" or something like that as the things that you wrote doesn't apply to our project
created_at: 2025-04-29T17:54:41Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
+* May require future migration or scaling strategy if the project grows or if Oracle VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+:status: Accepted
+:date: 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed due to its popularity and alignment with distributed systems.
+However, after evaluating the complexity and actual needs of the project, a service-based architecture was chosen instead.
+
+==== Decision
+
+The project adopts a service-based architecture, rather than a fully decoupled microservices model.
+
+==== Rationale
+
+* Provides modularization and separation of concerns without the overhead of managing independent deployments for each service.
+* Simplifies inter-service communication by avoiding complex patterns such as service discovery, load balancing, and distributed configuration.
+* Better aligns with the existing project base and team size, facilitating easier maintenance and deployment.
+* Reduces initial development and operational complexity.
+
+==== Alternatives considered
+
+*Pure Microservices Architecture*
+
+** Pros:
+  *** Strong decoupling, allowing for independent scaling and deployment of services.
+  *** Improved fault isolation and technology diversity.
+** Cons:
+  *** High operational complexity (e.g., service orchestration, distributed logging, network latency).
+  *** Requires significant infrastructure (service registry, message brokers, etc.).
+  *** Overkill for small or medium-sized teams and projects with limited domain boundaries.
+
+==== Consequences
+
+* Enables a modular structure where services are separated logically but may coexist within the same deployment unit.
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: They don't
created_at: 2025-04-29T17:55:03Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
+* May require future migration or scaling strategy if the project grows or if Oracle VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+:status: Accepted
+:date: 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed due to its popularity and alignment with distributed systems.
+However, after evaluating the complexity and actual needs of the project, a service-based architecture was chosen instead.
+
+==== Decision
+
+The project adopts a service-based architecture, rather than a fully decoupled microservices model.
+
+==== Rationale
+
+* Provides modularization and separation of concerns without the overhead of managing independent deployments for each service.
+* Simplifies inter-service communication by avoiding complex patterns such as service discovery, load balancing, and distributed configuration.
+* Better aligns with the existing project base and team size, facilitating easier maintenance and deployment.
+* Reduces initial development and operational complexity.
+
+==== Alternatives considered
+
+*Pure Microservices Architecture*
+
+** Pros:
+  *** Strong decoupling, allowing for independent scaling and deployment of services.
+  *** Improved fault isolation and technology diversity.
+** Cons:
+  *** High operational complexity (e.g., service orchestration, distributed logging, network latency).
+  *** Requires significant infrastructure (service registry, message brokers, etc.).
+  *** Overkill for small or medium-sized teams and projects with limited domain boundaries.
+
+==== Consequences
+
+* Enables a modular structure where services are separated logically but may coexist within the same deployment unit.
+* Facilitates faster development and easier testing.
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: Why?
created_at: 2025-04-29T17:56:09Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
+* May require future migration or scaling strategy if the project grows or if Oracle VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+:status: Accepted
+:date: 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed due to its popularity and alignment with distributed systems.
+However, after evaluating the complexity and actual needs of the project, a service-based architecture was chosen instead.
+
+==== Decision
+
+The project adopts a service-based architecture, rather than a fully decoupled microservices model.
+
+==== Rationale
+
+* Provides modularization and separation of concerns without the overhead of managing independent deployments for each service.
+* Simplifies inter-service communication by avoiding complex patterns such as service discovery, load balancing, and distributed configuration.
+* Better aligns with the existing project base and team size, facilitating easier maintenance and deployment.
+* Reduces initial development and operational complexity.
+
+==== Alternatives considered
+
+*Pure Microservices Architecture*
+
+** Pros:
+  *** Strong decoupling, allowing for independent scaling and deployment of services.
+  *** Improved fault isolation and technology diversity.
+** Cons:
+  *** High operational complexity (e.g., service orchestration, distributed logging, network latency).
+  *** Requires significant infrastructure (service registry, message brokers, etc.).
+  *** Overkill for small or medium-sized teams and projects with limited domain boundaries.
+
+==== Consequences
+
+* Enables a modular structure where services are separated logically but may coexist within the same deployment unit.
+* Facilitates faster development and easier testing.
+* Allows future evolution toward microservices if project requirements grow.
+* Some architectural trade-offs accepted, such as shared deployments or tighter coupling in certain areas.
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: We don't share deployment and why is there tighter coupling
created_at: 2025-04-29T17:56:43Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
+* May require future migration or scaling strategy if the project grows or if Oracle VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+:status: Accepted
+:date: 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed due to its popularity and alignment with distributed systems.
+However, after evaluating the complexity and actual needs of the project, a service-based architecture was chosen instead.
+
+==== Decision
+
+The project adopts a service-based architecture, rather than a fully decoupled microservices model.
+
+==== Rationale
+
+* Provides modularization and separation of concerns without the overhead of managing independent deployments for each service.
+* Simplifies inter-service communication by avoiding complex patterns such as service discovery, load balancing, and distributed configuration.
+* Better aligns with the existing project base and team size, facilitating easier maintenance and deployment.
+* Reduces initial development and operational complexity.
+
+==== Alternatives considered
+
+*Pure Microservices Architecture*
+
+** Pros:
+  *** Strong decoupling, allowing for independent scaling and deployment of services.
+  *** Improved fault isolation and technology diversity.
+** Cons:
+  *** High operational complexity (e.g., service orchestration, distributed logging, network latency).
+  *** Requires significant infrastructure (service registry, message brokers, etc.).
+  *** Overkill for small or medium-sized teams and projects with limited domain boundaries.
+
+==== Consequences
+
+* Enables a modular structure where services are separated logically but may coexist within the same deployment unit.
+* Facilitates faster development and easier testing.
+* Allows future evolution toward microservices if project requirements grow.
+* Some architectural trade-offs accepted, such as shared deployments or tighter coupling in certain areas.
+
+
+
+
+[[ADR-007]]
+=== ADR 007: Data Storage for Wikidata Information
+:status: Accepted
+:date: 
+
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: Mention that it's storaged in cache
created_at: 2025-04-29T17:57:42Z
author_association: NONE
diff_hunk: @@ -22,10 +22,40 @@ image:06-login.png["Runtime view - Logging in"]
 
 When it comes to logging in, the user firstly enters their credentials, then the back end retrieves the user's information from the database and verifies if it's correct.
 
-=== Future diagrams
 
-Once we have made progress in the development of the application, the following diagrams should be created according to the chosen implementation:
+=== Questions generation
+&nbsp;
+
+image:06-questionGeneration.png["Runtime view - Question generation"]
path: docs/src/06_runtime_view.adoc
user: login: LucasGisb
body: I dont put the name of a specific file in any diagram, i think its better like this. And i dont see that big of a difference between Game and Game.jsx to be honest (also I dont really want to redo a diagram for a reason like this)
created_at: 2025-04-30T17:43:11Z
author_association: NONE
diff_hunk: @@ -22,10 +22,40 @@ image:06-login.png["Runtime view - Logging in"]
 
 When it comes to logging in, the user firstly enters their credentials, then the back end retrieves the user's information from the database and verifies if it's correct.
 
-=== Future diagrams
 
-Once we have made progress in the development of the application, the following diagrams should be created according to the chosen implementation:
+=== Questions generation
+&nbsp;
+
+image:06-questionGeneration.png["Runtime view - Question generation"]
+
+&nbsp;
+
+The user accesses the game, selects its mode and difficulty, and the call is made. The backend is responsible for obtaining the questions (along with their images and answers) and transmitting them to the frontend.
+
+=== WiChat quiz game
+&nbsp;
+
+image:06-gameCycle.png["Runtime view - Game cycle"]
+
+&nbsp;
+
+
+The user enters the game, selects the mode and difficulty, and once the question is answered, the user begins the game, answering each question until the timer runs out, ending the game. After the game ends, and after the information has been saved, the user can replay the game or access other views.
+
+=== Obtaining hints via Chatbot
+&nbsp;
+
+image:06-chatBotFunctionality.png["Runtime view - Hints by chatbot"]
path: docs/src/06_runtime_view.adoc
user: login: LucasGisb
body: I really feel, liem I said earlier, that puttinf filesnames rather than the functionality itself would aggravate the diagram if anything else
created_at: 2025-04-30T17:45:03Z
author_association: NONE
diff_hunk: @@ -22,10 +22,40 @@ image:06-login.png["Runtime view - Logging in"]
 
 When it comes to logging in, the user firstly enters their credentials, then the back end retrieves the user's information from the database and verifies if it's correct.
 
-=== Future diagrams
 
-Once we have made progress in the development of the application, the following diagrams should be created according to the chosen implementation:
+=== Questions generation
+&nbsp;
+
+image:06-questionGeneration.png["Runtime view - Question generation"]
+
+&nbsp;
+
+The user accesses the game, selects its mode and difficulty, and the call is made. The backend is responsible for obtaining the questions (along with their images and answers) and transmitting them to the frontend.
+
+=== WiChat quiz game
+&nbsp;
+
+image:06-gameCycle.png["Runtime view - Game cycle"]
+
+&nbsp;
+
+
+The user enters the game, selects the mode and difficulty, and once the question is answered, the user begins the game, answering each question until the timer runs out, ending the game. After the game ends, and after the information has been saved, the user can replay the game or access other views.
+
+=== Obtaining hints via Chatbot
+&nbsp;
+
+image:06-chatBotFunctionality.png["Runtime view - Hints by chatbot"]
+
+&nbsp;
+
+In the Game view, the user types their questions into the Chatbot component, which are then sent to the LLM, where the prompt to be passed to the AI ​​is configured and the response is generated, which is then returned to the frontend for the user to view.
+
+=== Leaderboard and match search
+&nbsp;
+
+image:06-leaderboardAndSearch.png["Runtime view - Leaderboard and match search"]
path: docs/src/06_runtime_view.adoc
user: login: LucasGisb
body: Ok
created_at: 2025-04-30T17:45:59Z
author_association: NONE
diff_hunk: @@ -57,47 +57,62 @@ See https://docs.arc42.org/section-8/[Concepts] in the arc42 documentation.
 ****
 endif::arc42help[]
 
-=== _Continuous integration and development_
+=== _Domain concepts_
 
+|===
+| *Class* | *Explanation*
+| User | The people using the application, playing matches and generating statistics of their own.
+| Statistics | Given the performance of the player in its matches, relevant information is stored.
+| Match | Created when the user starts a game and includes its general information and generated questions.
+| Question | Questions spawned in a match, storing all its answers.
+| Answer | Every answer associated to a match's question, saving if it was the correct option and if was selected by the player.
+|===
+image:08-domainModel.png["Concepts - Domain Model"]
+
+
+=== _"Under-the-hood"_
+
+* *Backend*:  
+  The server-side logic of the application is implemented using Node.js in combination with the Express framework. The backend handles client requests, communicates with external services such as Wikidata and Gemini, manages user sessions, interacts with the database and other functionalities.
+
+* *Frontend*:  
+  The frontend is developed using React, a component-based JavaScript library that enables the creation of dynamic and interactive user interfaces. The frontend is responsible for rendering the game interface, managing user input, and presenting questions, hints, and scores.
+
+* *Database and persistence*:  
+  MongoDB serves as the main data store, offering a flexible document-oriented model that aligns well with the evolving structure of game data. It stores user profiles, game progress, generated questions, and historical results in JSON-like documents.
+
+* *LLM Integration*:  
+  We utilize Gemini, a Large Language Model (LLM), to enhance the gameplay experience by generating intelligent and context-aware hints for each question in real time.
+
+* *External Data Source*:  
+  To keep the game content rich and dynamic, we integrate Wikidata as our primary external knowledge source. Through its public REST API, we query up-to-date and structured information about a wide range of topics. This enables automatic generation of questions based on real-world data.
+
+
+
+=== _Development concepts_
+* *Continuous integration and development*
 Our way of working with github is having one developing branch towards which all pull requests are done 
 and have to be reviewed by at least one team member. 
 Sonar Cloud is set up so we know the testing coverage and whether we pass the quality gate with every pull request.
 Once there is enough change in the develop branch with respect to the main one and it has enough quality we can 
 merge them and make a release.
 
+* *Testings*
+One of the most important aspects is testing our application, and to achieve this, we will conduct different types of tests. On one hand, we will perform tests such as unit testing and usability testing. On the other hand, we will implement a continuous testing system using GitHub Actions, ensuring that all commits pass the required tests.
 
-=== _Microservice based system_
-
-Different business functionallities will be developed in different independent services.
-This will ensure that if one of them fails, the rest are still working (For example,
-if the rankings go down that will not affect the main game) as they have their own deployment
-as well. 
-Other benefits are increased maintainability due to separation in small, more readable modules
-and the possibillity of using different languages or technologies for each module if needed/prefered 
-without colliding with the rest.
-
-
-=== _Gateway service routing_
-
+=== _Operational concepts_
+* *Gateway service routing*
 We will use a speciallized service that will route the requests to the corresponding service, acting as 
 a single entry point for the application. Requests to the services are much simpler as only the api base 
 endpoint and the action needs to be known and the gateway can also act as a filter to manage requests 
 conditionally if needed. This approach also favors security as we can control which requests are actually 
 sent based on its content or the context of the app.
 
-=== _Authentication_
-
+=== _Safety and security concepts_
+* *Authentication*
 To keep our users' data secure an authentication mechanism has been developed with the use of JSON Web Tokens (JWT). If someone tries to access historical game records for certain users, our KaW application enforces to pass a valid token through the header of the message request.
path: docs/src/08_concepts.adoc
user: login: LucasGisb
body: A typo, sorry
created_at: 2025-04-30T17:46:30Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
path: docs/src/09_architecture_decisions.adoc
user: login: LucasGisb
body: I think it is better to represent the information more directly.
It is true that the last two ones could be unified for more clarity
created_at: 2025-04-30T17:49:01Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
path: docs/src/09_architecture_decisions.adoc
user: login: LucasGisb
body: It isnt stated that it was already integrated (i dont get your point)
created_at: 2025-04-30T17:51:47Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
path: docs/src/09_architecture_decisions.adoc
user: login: LucasGisb
body: As I wanted to comment the posibilities of relational databases, i decided to extended it in its own ADR. But I can put in this place a reference to it
created_at: 2025-04-30T17:53:31Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
path: docs/src/09_architecture_decisions.adoc
user: login: LucasGisb
body: Ok
created_at: 2025-04-30T17:53:48Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
path: docs/src/09_architecture_decisions.adoc
user: login: LucasGisb
body: Ok
created_at: 2025-04-30T17:53:58Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
path: docs/src/09_architecture_decisions.adoc
user: login: LucasGisb
body: OK
created_at: 2025-04-30T17:54:14Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
path: docs/src/09_architecture_decisions.adoc
user: login: LucasGisb
body: Ok
created_at: 2025-04-30T17:54:36Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
+* May require future migration or scaling strategy if the project grows or if Oracle VM limitations become restrictive.
path: docs/src/09_architecture_decisions.adoc
user: login: LucasGisb
body: Well yes, but it apllies to our current choice
created_at: 2025-04-30T17:55:35Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
+* May require future migration or scaling strategy if the project grows or if Oracle VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+:status: Accepted
+:date: 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed due to its popularity and alignment with distributed systems.
path: docs/src/09_architecture_decisions.adoc
user: login: LucasGisb
body: Ok
created_at: 2025-04-30T17:55:44Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
+* May require future migration or scaling strategy if the project grows or if Oracle VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+:status: Accepted
+:date: 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed due to its popularity and alignment with distributed systems.
+However, after evaluating the complexity and actual needs of the project, a service-based architecture was chosen instead.
+
+==== Decision
+
+The project adopts a service-based architecture, rather than a fully decoupled microservices model.
+
+==== Rationale
+
+* Provides modularization and separation of concerns without the overhead of managing independent deployments for each service.
+* Simplifies inter-service communication by avoiding complex patterns such as service discovery, load balancing, and distributed configuration.
+* Better aligns with the existing project base and team size, facilitating easier maintenance and deployment.
+* Reduces initial development and operational complexity.
+
+==== Alternatives considered
+
+*Pure Microservices Architecture*
+
+** Pros:
+  *** Strong decoupling, allowing for independent scaling and deployment of services.
+  *** Improved fault isolation and technology diversity.
path: docs/src/09_architecture_decisions.adoc
user: login: LucasGisb
body: Ok
created_at: 2025-04-30T17:56:29Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
+* May require future migration or scaling strategy if the project grows or if Oracle VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+:status: Accepted
+:date: 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed due to its popularity and alignment with distributed systems.
+However, after evaluating the complexity and actual needs of the project, a service-based architecture was chosen instead.
+
+==== Decision
+
+The project adopts a service-based architecture, rather than a fully decoupled microservices model.
+
+==== Rationale
+
+* Provides modularization and separation of concerns without the overhead of managing independent deployments for each service.
+* Simplifies inter-service communication by avoiding complex patterns such as service discovery, load balancing, and distributed configuration.
+* Better aligns with the existing project base and team size, facilitating easier maintenance and deployment.
+* Reduces initial development and operational complexity.
+
+==== Alternatives considered
+
+*Pure Microservices Architecture*
+
+** Pros:
+  *** Strong decoupling, allowing for independent scaling and deployment of services.
+  *** Improved fault isolation and technology diversity.
+** Cons:
+  *** High operational complexity (e.g., service orchestration, distributed logging, network latency).
+  *** Requires significant infrastructure (service registry, message brokers, etc.).
path: docs/src/09_architecture_decisions.adoc
user: login: LucasGisb
body: Ok
created_at: 2025-04-30T17:56:41Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
+* May require future migration or scaling strategy if the project grows or if Oracle VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+:status: Accepted
+:date: 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed due to its popularity and alignment with distributed systems.
+However, after evaluating the complexity and actual needs of the project, a service-based architecture was chosen instead.
+
+==== Decision
+
+The project adopts a service-based architecture, rather than a fully decoupled microservices model.
+
+==== Rationale
+
+* Provides modularization and separation of concerns without the overhead of managing independent deployments for each service.
+* Simplifies inter-service communication by avoiding complex patterns such as service discovery, load balancing, and distributed configuration.
+* Better aligns with the existing project base and team size, facilitating easier maintenance and deployment.
+* Reduces initial development and operational complexity.
+
+==== Alternatives considered
+
+*Pure Microservices Architecture*
+
+** Pros:
+  *** Strong decoupling, allowing for independent scaling and deployment of services.
+  *** Improved fault isolation and technology diversity.
+** Cons:
+  *** High operational complexity (e.g., service orchestration, distributed logging, network latency).
path: docs/src/09_architecture_decisions.adoc
user: login: LucasGisb
body: ejemples
Ok
created_at: 2025-04-30T17:58:22Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
+* May require future migration or scaling strategy if the project grows or if Oracle VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+:status: Accepted
+:date: 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed due to its popularity and alignment with distributed systems.
+However, after evaluating the complexity and actual needs of the project, a service-based architecture was chosen instead.
+
+==== Decision
+
+The project adopts a service-based architecture, rather than a fully decoupled microservices model.
+
+==== Rationale
+
+* Provides modularization and separation of concerns without the overhead of managing independent deployments for each service.
+* Simplifies inter-service communication by avoiding complex patterns such as service discovery, load balancing, and distributed configuration.
+* Better aligns with the existing project base and team size, facilitating easier maintenance and deployment.
+* Reduces initial development and operational complexity.
+
+==== Alternatives considered
+
+*Pure Microservices Architecture*
+
+** Pros:
+  *** Strong decoupling, allowing for independent scaling and deployment of services.
+  *** Improved fault isolation and technology diversity.
+** Cons:
+  *** High operational complexity (e.g., service orchestration, distributed logging, network latency).
+  *** Requires significant infrastructure (service registry, message brokers, etc.).
+  *** Overkill for small or medium-sized teams and projects with limited domain boundaries.
+
+==== Consequences
+
+* Enables a modular structure where services are separated logically but may coexist within the same deployment unit.
path: docs/src/09_architecture_decisions.adoc
user: login: LucasGisb
body: Ok
created_at: 2025-04-30T17:58:36Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
+* May require future migration or scaling strategy if the project grows or if Oracle VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+:status: Accepted
+:date: 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed due to its popularity and alignment with distributed systems.
+However, after evaluating the complexity and actual needs of the project, a service-based architecture was chosen instead.
+
+==== Decision
+
+The project adopts a service-based architecture, rather than a fully decoupled microservices model.
+
+==== Rationale
+
+* Provides modularization and separation of concerns without the overhead of managing independent deployments for each service.
+* Simplifies inter-service communication by avoiding complex patterns such as service discovery, load balancing, and distributed configuration.
+* Better aligns with the existing project base and team size, facilitating easier maintenance and deployment.
+* Reduces initial development and operational complexity.
+
+==== Alternatives considered
+
+*Pure Microservices Architecture*
+
+** Pros:
+  *** Strong decoupling, allowing for independent scaling and deployment of services.
+  *** Improved fault isolation and technology diversity.
+** Cons:
+  *** High operational complexity (e.g., service orchestration, distributed logging, network latency).
+  *** Requires significant infrastructure (service registry, message brokers, etc.).
+  *** Overkill for small or medium-sized teams and projects with limited domain boundaries.
+
+==== Consequences
+
+* Enables a modular structure where services are separated logically but may coexist within the same deployment unit.
+* Facilitates faster development and easier testing.
path: docs/src/09_architecture_decisions.adoc
user: login: LucasGisb
body: As we can do the tests given our entire application and not develop test for each one in a isolated way
created_at: 2025-04-30T18:00:19Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
+* May require future migration or scaling strategy if the project grows or if Oracle VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+:status: Accepted
+:date: 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed due to its popularity and alignment with distributed systems.
+However, after evaluating the complexity and actual needs of the project, a service-based architecture was chosen instead.
+
+==== Decision
+
+The project adopts a service-based architecture, rather than a fully decoupled microservices model.
+
+==== Rationale
+
+* Provides modularization and separation of concerns without the overhead of managing independent deployments for each service.
+* Simplifies inter-service communication by avoiding complex patterns such as service discovery, load balancing, and distributed configuration.
+* Better aligns with the existing project base and team size, facilitating easier maintenance and deployment.
+* Reduces initial development and operational complexity.
+
+==== Alternatives considered
+
+*Pure Microservices Architecture*
+
+** Pros:
+  *** Strong decoupling, allowing for independent scaling and deployment of services.
+  *** Improved fault isolation and technology diversity.
+** Cons:
+  *** High operational complexity (e.g., service orchestration, distributed logging, network latency).
+  *** Requires significant infrastructure (service registry, message brokers, etc.).
+  *** Overkill for small or medium-sized teams and projects with limited domain boundaries.
+
+==== Consequences
+
+* Enables a modular structure where services are separated logically but may coexist within the same deployment unit.
+* Facilitates faster development and easier testing.
+* Allows future evolution toward microservices if project requirements grow.
+* Some architectural trade-offs accepted, such as shared deployments or tighter coupling in certain areas.
path: docs/src/09_architecture_decisions.adoc
user: login: LucasGisb
body: Yes, not correct
created_at: 2025-04-30T18:00:32Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
+* May require future migration or scaling strategy if the project grows or if Oracle VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+:status: Accepted
+:date: 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed due to its popularity and alignment with distributed systems.
+However, after evaluating the complexity and actual needs of the project, a service-based architecture was chosen instead.
+
+==== Decision
+
+The project adopts a service-based architecture, rather than a fully decoupled microservices model.
+
+==== Rationale
+
+* Provides modularization and separation of concerns without the overhead of managing independent deployments for each service.
+* Simplifies inter-service communication by avoiding complex patterns such as service discovery, load balancing, and distributed configuration.
+* Better aligns with the existing project base and team size, facilitating easier maintenance and deployment.
+* Reduces initial development and operational complexity.
+
+==== Alternatives considered
+
+*Pure Microservices Architecture*
+
+** Pros:
+  *** Strong decoupling, allowing for independent scaling and deployment of services.
+  *** Improved fault isolation and technology diversity.
+** Cons:
+  *** High operational complexity (e.g., service orchestration, distributed logging, network latency).
+  *** Requires significant infrastructure (service registry, message brokers, etc.).
+  *** Overkill for small or medium-sized teams and projects with limited domain boundaries.
+
+==== Consequences
+
+* Enables a modular structure where services are separated logically but may coexist within the same deployment unit.
+* Facilitates faster development and easier testing.
+* Allows future evolution toward microservices if project requirements grow.
+* Some architectural trade-offs accepted, such as shared deployments or tighter coupling in certain areas.
+
+
+
+
+[[ADR-007]]
+=== ADR 007: Data Storage for Wikidata Information
+:status: Accepted
+:date: 
+
path: docs/src/09_architecture_decisions.adoc
user: login: LucasGisb
body: Ok
created_at: 2025-04-30T18:00:42Z
author_association: NONE
diff_hunk: @@ -38,7 +36,7 @@ The master branch contains the final version of the product, so that every accep
 * *Documentation*: it must be always updated for making our work valuable and consistent.
 * *Weekly meetings*: Weekly discussions about what has been done and what needs to be done will be key for our team success. 
 * *Github*: this control version systems not only allows us to share and collabortively write code, but also provides other resources such as issues and project management (kanban board) tools for organizing the work to be done. Also, wiki section allows us to save all of our minutes from each scheduled meeting.
-* *Whatsapp and Discord*: will allow us to be in constant communication for helping each other out whenever needed. 
+* *Whatsapp and Discord*: THey allow us to be in constant communication for helping each other out whenever needed. 
path: docs/src/04_solution_strategy.adoc
user: login: ElPandaP
body: They*
created_at: 2025-05-02T03:17:52Z
author_association: NONE
diff_hunk: @@ -38,7 +36,7 @@ The master branch contains the final version of the product, so that every accep
 * *Documentation*: it must be always updated for making our work valuable and consistent.
 * *Weekly meetings*: Weekly discussions about what has been done and what needs to be done will be key for our team success. 
 * *Github*: this control version systems not only allows us to share and collabortively write code, but also provides other resources such as issues and project management (kanban board) tools for organizing the work to be done. Also, wiki section allows us to save all of our minutes from each scheduled meeting.
-* *Whatsapp and Discord*: will allow us to be in constant communication for helping each other out whenever needed. 
+* *Whatsapp and Discord*: THey allow us to be in constant communication for helping each other out whenever needed. 
path: docs/src/04_solution_strategy.adoc
user: login: ElPandaP
body: Also, I would start with 'Allow' since 'They' sounds a bit strange when referring to companies
created_at: 2025-05-02T03:21:27Z
author_association: NONE
diff_hunk: @@ -22,10 +22,40 @@ image:06-login.png["Runtime view - Logging in"]
 
 When it comes to logging in, the user firstly enters their credentials, then the back end retrieves the user's information from the database and verifies if it's correct.
 
-=== Future diagrams
 
-Once we have made progress in the development of the application, the following diagrams should be created according to the chosen implementation:
+=== Questions generation
+&nbsp;
+
+image:06-questionGeneration.png["Runtime view - Question generation"]
+
+&nbsp;
+
+The user accesses the game, selects its mode and difficulty, and the call is made. The backend is responsible for obtaining the questions (along with their images and answers) and transmitting them to the frontend.
+
+=== WiChat quiz game
+&nbsp;
+
+image:06-gameCycle.png["Runtime view - Game cycle"]
+
+&nbsp;
+
+
+The user enters the game, selects the mode and difficulty, and once the question is answered, the user begins the game, answering each question until the timer runs out, ending the game. After the game ends, and after the information has been saved, the user can replay the game or access other views.
+
+=== Obtaining hints via Chatbot
+&nbsp;
+
+image:06-chatBotFunctionality.png["Runtime view - Hints by chatbot"]
+
+&nbsp;
+
+In the Game view, the user types their questions into the Chatbot component, which are then sent to the LLM, where the prompt to be passed to the AI ​​is configured and the response is generated, which is then returned to the frontend for the user to view.
+
+=== Leaderboard and match search
+&nbsp;
+
+image:06-leaderboardAndSearch.png["Runtime view - Leaderboard and match search"]
+
+&nbsp;
 
-==== Questions generation
-==== WiChat quiz game
-==== Obtaining hints via Chatbot
+The user accesses the Leaderboard, and on the one hand, data related to rankings and users is loaded, and on the other, the user can search for games by typing the name in the search input.
path: docs/src/06_runtime_view.adoc
user: login: ElPandaP
body: Revise
created_at: 2025-05-02T03:36:07Z
author_association: NONE
diff_hunk: @@ -57,47 +57,59 @@ See https://docs.arc42.org/section-8/[Concepts] in the arc42 documentation.
 ****
 endif::arc42help[]
 
-=== _Continuous integration and development_
+=== _Domain concepts_
 
+|===
+| *Class* | *Explanation*
+| User | The people using the application, playing matches and generating statistics of their own.
+| Statistics | Given the performance of the player in its matches, relevant information is stored.
+| Match | Created when the user starts a game and includes its general information and generated questions.
+| Question | Questions spawned in a match, storing all its answers.
+| Answer | Every answer associated to a match's question, saving if it was the correct option and if was selected by the player.
+|===
+image:08-domainModel.png["Concepts - Domain Model"]
+
+
+=== _"Under-the-hood"_
+
+* *Backend*:  
+  The server-side logic of the application is implemented using Node.js in combination with the Express framework. The backend handles client requests, communicates with external services such as Wikidata and Empathy, manages user sessions, interacts with the database and other functionalities.
+
+* *Frontend*:  
+  The frontend is developed using React, a component-based JavaScript library that enables the creation of dynamic and interactive user interfaces. The frontend is responsible for rendering the game interface, managing user input, and presenting questions, hints, and scores.
+
+* *Database and persistence*:  
+  MongoDB serves as the main data store, offering a flexible document-oriented model that aligns well with the evolving structure of game data. It stores user profiles, game progress, generated questions, and historical results in JSON-like documents.
+
+* *LLM Integration*:  
+  We utilize Empathy, a Large Language Model (LLM), to enhance the gameplay experience by generating intelligent and context-aware hints for each question in real time.
+
+* *External Data Source*:  
+  To keep the game content rich and dynamic, we integrate Wikidata as our primary external knowledge source. Through its public REST API, we query up-to-date and structured information about a wide range of topics. This enables automatic generation of questions based on real-world data.
+
+
+
+=== _Development concepts_
+* *Continuous integration and development*
 Our way of working with github is having one developing branch towards which all pull requests are done 
 and have to be reviewed by at least one team member. 
 Sonar Cloud is set up so we know the testing coverage and whether we pass the quality gate with every pull request.
 Once there is enough change in the develop branch with respect to the main one and it has enough quality we can 
 merge them and make a release.
 
+* *Testings*
+One of the most important aspects is testing our application, and to achieve this, we will conduct different types of tests. On one hand, we will perform tests such as unit testing and usability testing. On the other hand, we will implement a continuous testing system using GitHub Actions, ensuring that all commits pass the required tests.
 
-=== _Microservice based system_
-
-Different business functionallities will be developed in different independent services.
-This will ensure that if one of them fails, the rest are still working (For example,
-if the rankings go down that will not affect the main game) as they have their own deployment
-as well. 
-Other benefits are increased maintainability due to separation in small, more readable modules
-and the possibillity of using different languages or technologies for each module if needed/prefered 
-without colliding with the rest.
-
-
-=== _Gateway service routing_
-
+=== _Operational concepts_
+* *Gateway service routing*
 We will use a speciallized service that will route the requests to the corresponding service, acting as 
 a single entry point for the application. Requests to the services are much simpler as only the api base 
 endpoint and the action needs to be known and the gateway can also act as a filter to manage requests 
 conditionally if needed. This approach also favors security as we can control which requests are actually 
 sent based on its content or the context of the app.
 
-=== _Authentication_
-
-To keep our users' data secure an authentication mechanism has been developed with the use of JSON Web Tokens (JWT). If someone tries to access historical game records for certain users, our KaW application enforces to pass a valid token through the header of the message request.
-In this way, only authenticated users are able to consult the different data that our application enforces.
+=== _Safety and security concepts_
 
-=== _Internationalization_ 
+* *Secure storage*
+User passwords are never stored in plain text. Instead, secure hashing algorithms and encryption techniques are employed to protect sensitive information and prevent unauthorized access.
 
path: docs/src/08_concepts.adoc
user: login: ElPandaP
body: Put another BULLET POINT 😊 about Security redirections: the app redirects you to the login page if you try to access features that requires you to be logged and you are not
created_at: 2025-05-02T03:38:11Z
author_association: NONE
diff_hunk: @@ -57,47 +57,59 @@ See https://docs.arc42.org/section-8/[Concepts] in the arc42 documentation.
 ****
 endif::arc42help[]
 
-=== _Continuous integration and development_
+=== _Domain concepts_
 
+|===
+| *Class* | *Explanation*
+| User | The people using the application, playing matches and generating statistics of their own.
+| Statistics | Given the performance of the player in its matches, relevant information is stored.
+| Match | Created when the user starts a game and includes its general information and generated questions.
+| Question | Questions spawned in a match, storing all its answers.
+| Answer | Every answer associated to a match's question, saving if it was the correct option and if was selected by the player.
+|===
+image:08-domainModel.png["Concepts - Domain Model"]
+
+
+=== _"Under-the-hood"_
+
+* *Backend*:  
+  The server-side logic of the application is implemented using Node.js in combination with the Express framework. The backend handles client requests, communicates with external services such as Wikidata and Empathy, manages user sessions, interacts with the database and other functionalities.
+
+* *Frontend*:  
+  The frontend is developed using React, a component-based JavaScript library that enables the creation of dynamic and interactive user interfaces. The frontend is responsible for rendering the game interface, managing user input, and presenting questions, hints, and scores.
+
+* *Database and persistence*:  
+  MongoDB serves as the main data store, offering a flexible document-oriented model that aligns well with the evolving structure of game data. It stores user profiles, game progress, generated questions, and historical results in JSON-like documents.
+
+* *LLM Integration*:  
+  We utilize Empathy, a Large Language Model (LLM), to enhance the gameplay experience by generating intelligent and context-aware hints for each question in real time.
+
+* *External Data Source*:  
+  To keep the game content rich and dynamic, we integrate Wikidata as our primary external knowledge source. Through its public REST API, we query up-to-date and structured information about a wide range of topics. This enables automatic generation of questions based on real-world data.
+
+
+
+=== _Development concepts_
path: docs/src/08_concepts.adoc
user: login: ElPandaP
body: I'm not sure but maybe you should talk here about Docker and Github Actions
created_at: 2025-05-02T03:43:11Z
author_association: NONE
diff_hunk: @@ -57,47 +57,59 @@ See https://docs.arc42.org/section-8/[Concepts] in the arc42 documentation.
 ****
 endif::arc42help[]
 
-=== _Continuous integration and development_
+=== _Domain concepts_
 
+|===
+| *Class* | *Explanation*
+| User | The people using the application, playing matches and generating statistics of their own.
+| Statistics | Given the performance of the player in its matches, relevant information is stored.
+| Match | Created when the user starts a game and includes its general information and generated questions.
+| Question | Questions spawned in a match, storing all its answers.
+| Answer | Every answer associated to a match's question, saving if it was the correct option and if was selected by the player.
+|===
+image:08-domainModel.png["Concepts - Domain Model"]
+
+
+=== _"Under-the-hood"_
path: docs/src/08_concepts.adoc
user: login: ElPandaP
body: Maybe you should write about Swagger here
created_at: 2025-05-02T03:43:32Z
author_association: NONE
diff_hunk: @@ -1,44 +1,374 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Database:* MongoDB (see <<ADR-002>>)
+* *Deployment:* Docker
+
+==== Reasoning
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Reasoning
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+*Status: Proposed and Rejected*
+*:date: 16/03/2025* 
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Reasoning
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript. JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+*Status: Accepted*
+*:date: 16/03/2025* 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Reasoning
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle Cloud VM for Deployment Infrastructure
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+The application required a virtualized environment to deploy the frontend, backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and having almost every member of the team some level of experince, thanks to having used it in other subjects.
+
+However, during early planning, one team member already had access to an Oracle Cloud VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle Cloud VM instance to host the project infrastructure.
+
+==== Reasoning
+
+* Immediate availability of an Oracle Cloud VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+* With Oracle Cloud VM we can have the aplicattion deployed 24/7.
+* In case anyone have to do any kind of work on the VM, giving access to it is simple because only SSH and the IP are required.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+  *** In case we have used Azure, we would be obligated to turn on and off the application whenever it is necessary.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost during the development.
+* May require future migration or scaling strategy if the project grows or if Oracle Cloud VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed and followed due to its popularity and the main project was built in a microservice based architecture.
+However, during the development of the application, a service-based architecture was chosen instead.
+
+==== Decision
+
+The project adopts a service-based architecture, rather than a fully decoupled microservices model.
+
+==== Reasoning
+
+* Provides modularization and separation of concerns without the overhead of managing independent deployments for each service.
+* Simplifies inter-service communication by avoiding complex patterns such as service discovery, load balancing, and distributed configuration.
+* Better aligns with the existing project base and team size, facilitating easier maintenance and deployment.
+* Reduces initial development and operational complexity.
+
+==== Alternatives considered
+
+*Pure Microservices Architecture*
+
+** Pros:
+  *** Strong decoupling, allowing for independent scaling and deployment of services.
+** Cons:
+  *** Overkill for small or medium-sized teams and projects with limited domain boundaries.
+
+==== Consequences
+
+* Enables a modular structure where services are separated logically but may coexist within the application itself.
+* Facilitates faster development and easier testing.
+* Allows future evolution toward microservices if project requirements grow.
+
+
+
+[[ADR-007]]
+=== ADR 007: Data Storage for Wikidata Information
+*Status: Accepted*
+*:date: 16/03/2025* 
+
+==== Context
+
+Initially, the application fetched data from Wikidata in real time during gameplay to generate questions dynamically.
+However, this approach caused severe performance issues, resulting in noticeable delays that degraded the user experience during matches.
+
+==== Decision
+
+To improve performance, the application now pre-generates and stores a set of questions in the database at the start of each game.
+These stored questions are then served to the user dynamically throughout the match, minimizing latency.
+
+==== Reasoning
+
+* Real-time queries to Wikidata introduced unpredictable delays and negatively impacted gameplay flow.
+* Preloading questions ensures smooth and uninterrupted user experience.
+* Reduces dependency on external services during active sessions, making the game more stable and reliable.
+
+==== Alternatives considered
+
+*Inserting loading screens between questions*
+
+** Pros:
+  *** Would allow real-time querying to continue without significant architectural changes.
+  *** Could be visually appealing with the right UI/UX design.
+** Cons:
+  *** Did not solve the root performance issue — only masked it.
+  *** Introduced unwanted pauses that disrupted the game's pacing and fluidity.
+
+==== Consequences
+
+* Game sessions begin with a brief setup phase where questions are fetched and stored.
+* Once the session starts, question delivery is fast and reliable, improving overall experience.
+* The system is now more resilient to outages or slowdowns in the Wikidata SPARQL endpoint.
+
+
+
+[[ADR-008]]
+=== ADR 008: Styling Approach - CSS Modules
+*Status: Accepted*
+*:date: 16/03/2025* 
+
+==== Context
+
+Maintaining scoped styles without introducing unnecessary complexity.
+
+==== Decision
+
+Use CSS Modules for styling, with partial hybridization where needed.
+
+==== Reasoning
+
+* Keeps styles encapsulated.
+* Allows flexibility where global styles are needed.
+
+==== Consequences
+
+* Mixed styling approach may introduce slight overhead.
+
+
+[[ADR-009]]
+=== ADR 009: Choice of Empathy LLM
+*Status: Accepted*
+*:date: 07/04/2025* 
+
+==== Context
+
+To implement the chatbot system that provides hints during gameplay, the project required integration with a Large Language Model (LLM). The main criteria were accuracy, responsiveness, and a reduced tendency toward hallucination or incorrect answers, as the quality of hints directly affects user experience.
+
+==== Decision
+
+The team chose to use the Qwen2.5-Coder-7B-Instruct model provided through the Empathy LLM platform.
+
+==== Reasoning
+
+* Empathy LLM provided an API key with access to two models:
+  ** Mistral-7B-Instruct-v0.3
+  ** Qwen2.5-Coder-7B-Instruct
+* After testing both models, Qwen was selected for:
+  ** Higher consistency in structured, instructional outputs.
+  ** Better handling of technical prompts and explanation-style hints.
+  ** More stable performance with fewer hallucinations under our prompt style.
+* The Empathy API offered fast response times and easy integration, allowing for rapid prototyping and feedback iteration.
+
+==== Alternatives considered
+
+*Mistral-7B-Instruct-v0.3*
+
+** Pros:
+  *** Well-known model with good general performance.
+  *** Slightly faster in some shorter prompts.
+** Cons:
+  *** More prone to generating vague or verbose responses in our use case.
+  *** Occasionally less precise in multi-turn or guided question scenarios.
+
+==== Consequences
+
+* The chatbot feature benefits from a lightweight, instruction-tuned LLM tailored to the task.
+* Reduces hallucination risk, improving player trust in hints.
+* The choice of Qwen may require future fine-tuning or prompt engineering as feature complexity grows.
+* Integration is dependent on the continued availability and performance of the Empathy LLM platform.
+* In the future, a fallback strategy using both Qwen and Mistral could be implemented to improve resilience against outages or API failures.
+
+
 
-The service in charge of comunicating with WikiData will be coded using TypeSript. 
-As the generation of questions is a huge part of our application we will play it safe by using TypeSript, a language that is similar to JavaSript but with static type checking.
 
-*03/02/2025*
+[[ADR-010]]
+=== ADR 010: Monitoring Strategy   ******************************************************************************
+*Status: Accepted*
+*:date: 28/04/2025* 
 
-Microservices Architecture:
-The application will follow a Microservices architecture to ensure scalability, flexibility, and easier maintenance. This approach allows different services to be developed, deployed, and scaled independently, improving fault tolerance and facilitating continuous deployment.
+==== Context
 
-WikiData Service - TypeScript:
-The service responsible for communicating with WikiData will be developed using TypeScript. Since generating questions is a critical part of our application, we decided to use TypeScript due to its static type checking, which helps prevent runtime errors and makes the codebase more maintainable. Additionally, TypeScript provides better tooling support and improves developer productivity by reducing debugging time.
 
-Backend & Frontend Technologies:
-The backend will be built using Node.js, as it is efficient for handling asynchronous operations and provides a vast ecosystem of libraries.
-The frontend will be developed with React, a popular JavaScript library known for its component-based structure, performance optimizations, and reusability. React's virtual DOM improves rendering efficiency, making it a great choice for dynamic applications.
+==== Decision
 
-Database - MongoDB:
-We have chosen MongoDB, a NoSQL database, because it provides flexibility in handling unstructured data, horizontal scalability, and high availability. Given that our data structure may evolve over time, MongoDB’s schema-less nature allows us to adapt without complex migrations.
 
-Deployment Strategy:
-The application will be deployed on a server owned by one of the team members. This decision allows us to have full control over the deployment environment, reduce costs, and customize configurations based on our needs.
 
-*03/03/2025*
+==== Reasoning
 
-Switching from TypeScript to JavaScript:
-We initially opted for TypeScript to improve code quality through static typing. However, after encountering integration issues, increased complexity, and longer development time, we decided to switch to JavaScript. JavaScript allows for faster iteration, broader community support, and reduced setup overhead, making it more practical for our project timeline.
+* Prometheus + Grafana
+* Oracle Cloud Monitoring
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: Finally chosed prometheus and grafana since it was almost all configured. However I also considered Oracle Cloud Monitoring as I have more experience with it, if it hadn't been configured I would have done it with oracle cloud monitoring.
created_at: 2025-05-02T03:47:16Z
author_association: NONE
diff_hunk: @@ -1,44 +1,374 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Database:* MongoDB (see <<ADR-002>>)
+* *Deployment:* Docker
+
+==== Reasoning
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Reasoning
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+*Status: Proposed and Rejected*
+*:date: 16/03/2025* 
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Reasoning
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript. JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+*Status: Accepted*
+*:date: 16/03/2025* 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Reasoning
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle Cloud VM for Deployment Infrastructure
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+The application required a virtualized environment to deploy the frontend, backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and having almost every member of the team some level of experince, thanks to having used it in other subjects.
+
+However, during early planning, one team member already had access to an Oracle Cloud VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle Cloud VM instance to host the project infrastructure.
+
+==== Reasoning
+
+* Immediate availability of an Oracle Cloud VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+* With Oracle Cloud VM we can have the aplicattion deployed 24/7.
+* In case anyone have to do any kind of work on the VM, giving access to it is simple because only SSH and the IP are required.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+  *** In case we have used Azure, we would be obligated to turn on and off the application whenever it is necessary.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost during the development.
+* May require future migration or scaling strategy if the project grows or if Oracle Cloud VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed and followed due to its popularity and the main project was built in a microservice based architecture.
+However, during the development of the application, a service-based architecture was chosen instead.
+
+==== Decision
+
+The project adopts a service-based architecture, rather than a fully decoupled microservices model.
+
+==== Reasoning
+
+* Provides modularization and separation of concerns without the overhead of managing independent deployments for each service.
+* Simplifies inter-service communication by avoiding complex patterns such as service discovery, load balancing, and distributed configuration.
+* Better aligns with the existing project base and team size, facilitating easier maintenance and deployment.
+* Reduces initial development and operational complexity.
+
+==== Alternatives considered
+
+*Pure Microservices Architecture*
+
+** Pros:
+  *** Strong decoupling, allowing for independent scaling and deployment of services.
+** Cons:
+  *** Overkill for small or medium-sized teams and projects with limited domain boundaries.
+
+==== Consequences
+
+* Enables a modular structure where services are separated logically but may coexist within the application itself.
+* Facilitates faster development and easier testing.
+* Allows future evolution toward microservices if project requirements grow.
+
+
+
+[[ADR-007]]
+=== ADR 007: Data Storage for Wikidata Information
+*Status: Accepted*
+*:date: 16/03/2025* 
+
+==== Context
+
+Initially, the application fetched data from Wikidata in real time during gameplay to generate questions dynamically.
+However, this approach caused severe performance issues, resulting in noticeable delays that degraded the user experience during matches.
+
+==== Decision
+
+To improve performance, the application now pre-generates and stores a set of questions in the database at the start of each game.
+These stored questions are then served to the user dynamically throughout the match, minimizing latency.
+
+==== Reasoning
+
+* Real-time queries to Wikidata introduced unpredictable delays and negatively impacted gameplay flow.
+* Preloading questions ensures smooth and uninterrupted user experience.
+* Reduces dependency on external services during active sessions, making the game more stable and reliable.
+
+==== Alternatives considered
+
+*Inserting loading screens between questions*
+
+** Pros:
+  *** Would allow real-time querying to continue without significant architectural changes.
+  *** Could be visually appealing with the right UI/UX design.
+** Cons:
+  *** Did not solve the root performance issue — only masked it.
+  *** Introduced unwanted pauses that disrupted the game's pacing and fluidity.
+
+==== Consequences
+
+* Game sessions begin with a brief setup phase where questions are fetched and stored.
+* Once the session starts, question delivery is fast and reliable, improving overall experience.
+* The system is now more resilient to outages or slowdowns in the Wikidata SPARQL endpoint.
+
+
+
+[[ADR-008]]
+=== ADR 008: Styling Approach - CSS Modules
+*Status: Accepted*
+*:date: 16/03/2025* 
+
+==== Context
+
+Maintaining scoped styles without introducing unnecessary complexity.
+
+==== Decision
+
+Use CSS Modules for styling, with partial hybridization where needed.
+
+==== Reasoning
+
+* Keeps styles encapsulated.
+* Allows flexibility where global styles are needed.
+
+==== Consequences
+
+* Mixed styling approach may introduce slight overhead.
+
+
+[[ADR-009]]
+=== ADR 009: Choice of Empathy LLM
+*Status: Accepted*
+*:date: 07/04/2025* 
+
+==== Context
+
+To implement the chatbot system that provides hints during gameplay, the project required integration with a Large Language Model (LLM). The main criteria were accuracy, responsiveness, and a reduced tendency toward hallucination or incorrect answers, as the quality of hints directly affects user experience.
+
+==== Decision
+
+The team chose to use the Qwen2.5-Coder-7B-Instruct model provided through the Empathy LLM platform.
+
+==== Reasoning
+
+* Empathy LLM provided an API key with access to two models:
+  ** Mistral-7B-Instruct-v0.3
+  ** Qwen2.5-Coder-7B-Instruct
+* After testing both models, Qwen was selected for:
+  ** Higher consistency in structured, instructional outputs.
+  ** Better handling of technical prompts and explanation-style hints.
+  ** More stable performance with fewer hallucinations under our prompt style.
+* The Empathy API offered fast response times and easy integration, allowing for rapid prototyping and feedback iteration.
+
+==== Alternatives considered
+
+*Mistral-7B-Instruct-v0.3*
+
+** Pros:
+  *** Well-known model with good general performance.
+  *** Slightly faster in some shorter prompts.
+** Cons:
+  *** More prone to generating vague or verbose responses in our use case.
+  *** Occasionally less precise in multi-turn or guided question scenarios.
+
+==== Consequences
+
+* The chatbot feature benefits from a lightweight, instruction-tuned LLM tailored to the task.
+* Reduces hallucination risk, improving player trust in hints.
+* The choice of Qwen may require future fine-tuning or prompt engineering as feature complexity grows.
+* Integration is dependent on the continued availability and performance of the Empathy LLM platform.
+* In the future, a fallback strategy using both Qwen and Mistral could be implemented to improve resilience against outages or API failures.
+
+
 
-The service in charge of comunicating with WikiData will be coded using TypeSript. 
-As the generation of questions is a huge part of our application we will play it safe by using TypeSript, a language that is similar to JavaSript but with static type checking.
 
-*03/02/2025*
+[[ADR-010]]
+=== ADR 010: Monitoring Strategy   ******************************************************************************
+*Status: Accepted*
+*:date: 28/04/2025* 
 
-Microservices Architecture:
-The application will follow a Microservices architecture to ensure scalability, flexibility, and easier maintenance. This approach allows different services to be developed, deployed, and scaled independently, improving fault tolerance and facilitating continuous deployment.
+==== Context
 
-WikiData Service - TypeScript:
-The service responsible for communicating with WikiData will be developed using TypeScript. Since generating questions is a critical part of our application, we decided to use TypeScript due to its static type checking, which helps prevent runtime errors and makes the codebase more maintainable. Additionally, TypeScript provides better tooling support and improves developer productivity by reducing debugging time.
 
-Backend & Frontend Technologies:
-The backend will be built using Node.js, as it is efficient for handling asynchronous operations and provides a vast ecosystem of libraries.
-The frontend will be developed with React, a popular JavaScript library known for its component-based structure, performance optimizations, and reusability. React's virtual DOM improves rendering efficiency, making it a great choice for dynamic applications.
+==== Decision
 
-Database - MongoDB:
-We have chosen MongoDB, a NoSQL database, because it provides flexibility in handling unstructured data, horizontal scalability, and high availability. Given that our data structure may evolve over time, MongoDB’s schema-less nature allows us to adapt without complex migrations.
 
-Deployment Strategy:
-The application will be deployed on a server owned by one of the team members. This decision allows us to have full control over the deployment environment, reduce costs, and customize configurations based on our needs.
 
-*03/03/2025*
+==== Reasoning
 
-Switching from TypeScript to JavaScript:
-We initially opted for TypeScript to improve code quality through static typing. However, after encountering integration issues, increased complexity, and longer development time, we decided to switch to JavaScript. JavaScript allows for faster iteration, broader community support, and reduced setup overhead, making it more practical for our project timeline.
+* Prometheus + Grafana
+* Oracle Cloud Monitoring
 
-CSS Modules for Styling:
-We have chosen to use CSS Modules for styling because it:
+==== Consequences
 
-Prevents style conflicts by scoping styles to individual components.
-Improves maintainability by keeping styles modular and easy to manage.
-Enhances reusability as styles are encapsulated within their respective components, reducing the risk of unintended global overrides.
 
-These decisions were made to optimize performance, maintainability, and scalability while ensuring smooth development and deployment of our application.
 
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: Another point

DNS and Reverse proxy
I used duckdns as a free DNS that can "redirect" (internally, not in the client browser) wic2c.duckdns.org to the oracle vm ip, I used it because it was free and easy

I used nginx as a reverse proxy that "redirect" (internally, not in the client browser) requests from http://wic2c.duckdns.org (port 80) to http://wic2c.duckdns.org:3000
created_at: 2025-05-02T03:53:24Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: I'm saying I would put that as a Cons, or you can put that MongoDB was already integrated (in the main project) in the Reasoning tab. Also I would mention somewhere that MongoDB has better integration with JSON than SQL
created_at: 2025-05-02T03:58:46Z
author_association: NONE
diff_hunk: @@ -1,44 +1,374 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Database:* MongoDB (see <<ADR-002>>)
+* *Deployment:* Docker
+
+==== Reasoning
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Reasoning
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+*Status: Proposed and Rejected*
+*:date: 16/03/2025* 
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Reasoning
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript. JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+*Status: Accepted*
+*:date: 16/03/2025* 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Reasoning
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle Cloud VM for Deployment Infrastructure
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+The application required a virtualized environment to deploy the frontend, backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and having almost every member of the team some level of experince, thanks to having used it in other subjects.
+
+However, during early planning, one team member already had access to an Oracle Cloud VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle Cloud VM instance to host the project infrastructure.
+
+==== Reasoning
+
+* Immediate availability of an Oracle Cloud VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+* With Oracle Cloud VM we can have the aplicattion deployed 24/7.
+* In case anyone have to do any kind of work on the VM, giving access to it is simple because only SSH and the IP are required.
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: SSH key, not SSH
created_at: 2025-05-02T04:01:29Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
+* May require future migration or scaling strategy if the project grows or if Oracle VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+:status: Accepted
+:date: 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed due to its popularity and alignment with distributed systems.
+However, after evaluating the complexity and actual needs of the project, a service-based architecture was chosen instead.
+
+==== Decision
+
+The project adopts a service-based architecture, rather than a fully decoupled microservices model.
+
+==== Rationale
+
+* Provides modularization and separation of concerns without the overhead of managing independent deployments for each service.
+* Simplifies inter-service communication by avoiding complex patterns such as service discovery, load balancing, and distributed configuration.
+* Better aligns with the existing project base and team size, facilitating easier maintenance and deployment.
+* Reduces initial development and operational complexity.
+
+==== Alternatives considered
+
+*Pure Microservices Architecture*
+
+** Pros:
+  *** Strong decoupling, allowing for independent scaling and deployment of services.
+  *** Improved fault isolation and technology diversity.
+** Cons:
+  *** High operational complexity (e.g., service orchestration, distributed logging, network latency).
+  *** Requires significant infrastructure (service registry, message brokers, etc.).
+  *** Overkill for small or medium-sized teams and projects with limited domain boundaries.
+
+==== Consequences
+
+* Enables a modular structure where services are separated logically but may coexist within the same deployment unit.
+* Facilitates faster development and easier testing.
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: I don't get it, we do them isolated as far as I know. Also I'm not sure why that is an advantage
created_at: 2025-05-02T04:06:58Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
+* May require future migration or scaling strategy if the project grows or if Oracle VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+:status: Accepted
+:date: 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed due to its popularity and alignment with distributed systems.
+However, after evaluating the complexity and actual needs of the project, a service-based architecture was chosen instead.
+
+==== Decision
+
+The project adopts a service-based architecture, rather than a fully decoupled microservices model.
+
+==== Rationale
+
+* Provides modularization and separation of concerns without the overhead of managing independent deployments for each service.
+* Simplifies inter-service communication by avoiding complex patterns such as service discovery, load balancing, and distributed configuration.
+* Better aligns with the existing project base and team size, facilitating easier maintenance and deployment.
+* Reduces initial development and operational complexity.
+
+==== Alternatives considered
+
+*Pure Microservices Architecture*
+
+** Pros:
+  *** Strong decoupling, allowing for independent scaling and deployment of services.
+  *** Improved fault isolation and technology diversity.
+** Cons:
+  *** High operational complexity (e.g., service orchestration, distributed logging, network latency).
+  *** Requires significant infrastructure (service registry, message brokers, etc.).
+  *** Overkill for small or medium-sized teams and projects with limited domain boundaries.
+
+==== Consequences
+
+* Enables a modular structure where services are separated logically but may coexist within the same deployment unit.
+* Facilitates faster development and easier testing.
+* Allows future evolution toward microservices if project requirements grow.
+* Some architectural trade-offs accepted, such as shared deployments or tighter coupling in certain areas.
+
+
+
+
+[[ADR-007]]
+=== ADR 007: Data Storage for Wikidata Information
+:status: Accepted
+:date: 
+
path: docs/src/09_architecture_decisions.adoc
user: login: ElPandaP
body: Emm you did not
created_at: 2025-05-02T04:07:52Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
+* May require future migration or scaling strategy if the project grows or if Oracle VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+:status: Accepted
+:date: 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed due to its popularity and alignment with distributed systems.
+However, after evaluating the complexity and actual needs of the project, a service-based architecture was chosen instead.
+
+==== Decision
+
+The project adopts a service-based architecture, rather than a fully decoupled microservices model.
+
+==== Rationale
+
+* Provides modularization and separation of concerns without the overhead of managing independent deployments for each service.
+* Simplifies inter-service communication by avoiding complex patterns such as service discovery, load balancing, and distributed configuration.
+* Better aligns with the existing project base and team size, facilitating easier maintenance and deployment.
+* Reduces initial development and operational complexity.
+
+==== Alternatives considered
+
+*Pure Microservices Architecture*
+
+** Pros:
+  *** Strong decoupling, allowing for independent scaling and deployment of services.
+  *** Improved fault isolation and technology diversity.
+** Cons:
+  *** High operational complexity (e.g., service orchestration, distributed logging, network latency).
+  *** Requires significant infrastructure (service registry, message brokers, etc.).
+  *** Overkill for small or medium-sized teams and projects with limited domain boundaries.
+
+==== Consequences
+
+* Enables a modular structure where services are separated logically but may coexist within the same deployment unit.
+* Facilitates faster development and easier testing.
+* Allows future evolution toward microservices if project requirements grow.
+* Some architectural trade-offs accepted, such as shared deployments or tighter coupling in certain areas.
+
+
+
+
+[[ADR-007]]
+=== ADR 007: Data Storage for Wikidata Information
+:status: Accepted
+:date: 
+
path: docs/src/09_architecture_decisions.adoc
user: login: LucasGisb
body: They does on the database, not cache (we talked with pablo about it)
created_at: 2025-05-02T20:33:17Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
path: docs/src/09_architecture_decisions.adoc
user: login: LucasGisb
body: Ok
created_at: 2025-05-02T20:36:09Z
author_association: NONE
diff_hunk: @@ -1,44 +1,376 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+:status: Accepted
+:date: 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Deployment:* Docker
+
+==== Rationale
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+:status: Accepted
+:date: 2025-04-28
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Rationale
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+:status: Proposed and Rejected
+:date: 2025-04-28
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Rationale
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript.
+* JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+:status: Accepted
+:date: 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Rationale
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle VM for Deployment Infrastructure
+:status: Accepted
+:date: 
+
+==== Context
+
+The application required a virtualized environment to deploy backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and enterprise-grade features.
+
+However, during early planning, one team member already had access to an Oracle VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle VM instance to host the project infrastructure.
+
+==== Rationale
+
+* Immediate availability of an Oracle VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost in early development phases.
+* May require future migration or scaling strategy if the project grows or if Oracle VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+:status: Accepted
+:date: 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed due to its popularity and alignment with distributed systems.
+However, after evaluating the complexity and actual needs of the project, a service-based architecture was chosen instead.
+
+==== Decision
+
+The project adopts a service-based architecture, rather than a fully decoupled microservices model.
+
+==== Rationale
+
+* Provides modularization and separation of concerns without the overhead of managing independent deployments for each service.
+* Simplifies inter-service communication by avoiding complex patterns such as service discovery, load balancing, and distributed configuration.
+* Better aligns with the existing project base and team size, facilitating easier maintenance and deployment.
+* Reduces initial development and operational complexity.
+
+==== Alternatives considered
+
+*Pure Microservices Architecture*
+
+** Pros:
+  *** Strong decoupling, allowing for independent scaling and deployment of services.
+  *** Improved fault isolation and technology diversity.
+** Cons:
+  *** High operational complexity (e.g., service orchestration, distributed logging, network latency).
+  *** Requires significant infrastructure (service registry, message brokers, etc.).
+  *** Overkill for small or medium-sized teams and projects with limited domain boundaries.
+
+==== Consequences
+
+* Enables a modular structure where services are separated logically but may coexist within the same deployment unit.
+* Facilitates faster development and easier testing.
path: docs/src/09_architecture_decisions.adoc
user: login: LucasGisb
body: I will explain the reason. If you disagree with that, i am sorry my friend
created_at: 2025-05-02T20:42:01Z
author_association: NONE
diff_hunk: @@ -1,44 +1,374 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Database:* MongoDB (see <<ADR-002>>)
+* *Deployment:* Docker
+
+==== Reasoning
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Reasoning
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+*Status: Proposed and Rejected*
+*:date: 16/03/2025* 
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Reasoning
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript. JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+*Status: Accepted*
+*:date: 16/03/2025* 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Reasoning
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle Cloud VM for Deployment Infrastructure
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+The application required a virtualized environment to deploy the frontend, backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and having almost every member of the team some level of experince, thanks to having used it in other subjects.
+
+However, during early planning, one team member already had access to an Oracle Cloud VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle Cloud VM instance to host the project infrastructure.
+
+==== Reasoning
+
+* Immediate availability of an Oracle Cloud VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+* With Oracle Cloud VM we can have the aplicattion deployed 24/7.
+* In case anyone have to do any kind of work on the VM, giving access to it is simple because only SSH and the IP are required.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+  *** In case we have used Azure, we would be obligated to turn on and off the application whenever it is necessary.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost during the development.
+* May require future migration or scaling strategy if the project grows or if Oracle Cloud VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed and followed due to its popularity and the main project was built in a microservice based architecture.
+However, during the development of the application, a service-based architecture was chosen instead.
+
+==== Decision
+
+The project adopts a service-based architecture, rather than a fully decoupled microservices model.
+
+==== Reasoning
+
+* Provides modularization and separation of concerns without the overhead of managing independent deployments for each service.
+* Simplifies inter-service communication by avoiding complex patterns such as service discovery, load balancing, and distributed configuration.
+* Better aligns with the existing project base and team size, facilitating easier maintenance and deployment.
+* Reduces initial development and operational complexity.
+
+==== Alternatives considered
+
+*Pure Microservices Architecture*
+
+** Pros:
+  *** Strong decoupling, allowing for independent scaling and deployment of services.
+** Cons:
+  *** Overkill for small or medium-sized teams and projects with limited domain boundaries.
+
+==== Consequences
+
+* Enables a modular structure where services are separated logically but may coexist within the application itself.
+* Facilitates faster development and easier testing.
+* Allows future evolution toward microservices if project requirements grow.
+
+
+
+[[ADR-007]]
+=== ADR 007: Data Storage for Wikidata Information
+*Status: Accepted*
+*:date: 16/03/2025* 
+
+==== Context
+
+Initially, the application fetched data from Wikidata in real time during gameplay to generate questions dynamically.
+However, this approach caused severe performance issues, resulting in noticeable delays that degraded the user experience during matches.
+
+==== Decision
+
+To improve performance, the application now pre-generates and stores a set of questions in the database at the start of each game.
+These stored questions are then served to the user dynamically throughout the match, minimizing latency.
+
+==== Reasoning
+
+* Real-time queries to Wikidata introduced unpredictable delays and negatively impacted gameplay flow.
+* Preloading questions ensures smooth and uninterrupted user experience.
+* Reduces dependency on external services during active sessions, making the game more stable and reliable.
+
+==== Alternatives considered
+
+*Inserting loading screens between questions*
+
+** Pros:
+  *** Would allow real-time querying to continue without significant architectural changes.
+  *** Could be visually appealing with the right UI/UX design.
+** Cons:
+  *** Did not solve the root performance issue — only masked it.
+  *** Introduced unwanted pauses that disrupted the game's pacing and fluidity.
+
+==== Consequences
+
+* Game sessions begin with a brief setup phase where questions are fetched and stored.
+* Once the session starts, question delivery is fast and reliable, improving overall experience.
+* The system is now more resilient to outages or slowdowns in the Wikidata SPARQL endpoint.
+
+
+
+[[ADR-008]]
+=== ADR 008: Styling Approach - CSS Modules
+*Status: Accepted*
+*:date: 16/03/2025* 
+
+==== Context
+
+Maintaining scoped styles without introducing unnecessary complexity.
+
+==== Decision
+
+Use CSS Modules for styling, with partial hybridization where needed.
+
+==== Reasoning
+
+* Keeps styles encapsulated.
+* Allows flexibility where global styles are needed.
+
+==== Consequences
+
+* Mixed styling approach may introduce slight overhead.
+
+
+[[ADR-009]]
+=== ADR 009: Choice of Empathy LLM
+*Status: Accepted*
+*:date: 07/04/2025* 
+
+==== Context
+
+To implement the chatbot system that provides hints during gameplay, the project required integration with a Large Language Model (LLM). The main criteria were accuracy, responsiveness, and a reduced tendency toward hallucination or incorrect answers, as the quality of hints directly affects user experience.
+
+==== Decision
+
+The team chose to use the Qwen2.5-Coder-7B-Instruct model provided through the Empathy LLM platform.
+
+==== Reasoning
+
+* Empathy LLM provided an API key with access to two models:
+  ** Mistral-7B-Instruct-v0.3
+  ** Qwen2.5-Coder-7B-Instruct
+* After testing both models, Qwen was selected for:
+  ** Higher consistency in structured, instructional outputs.
+  ** Better handling of technical prompts and explanation-style hints.
+  ** More stable performance with fewer hallucinations under our prompt style.
+* The Empathy API offered fast response times and easy integration, allowing for rapid prototyping and feedback iteration.
+
+==== Alternatives considered
+
+*Mistral-7B-Instruct-v0.3*
+
+** Pros:
+  *** Well-known model with good general performance.
+  *** Slightly faster in some shorter prompts.
+** Cons:
+  *** More prone to generating vague or verbose responses in our use case.
+  *** Occasionally less precise in multi-turn or guided question scenarios.
+
+==== Consequences
+
+* The chatbot feature benefits from a lightweight, instruction-tuned LLM tailored to the task.
+* Reduces hallucination risk, improving player trust in hints.
+* The choice of Qwen may require future fine-tuning or prompt engineering as feature complexity grows.
+* Integration is dependent on the continued availability and performance of the Empathy LLM platform.
+* In the future, a fallback strategy using both Qwen and Mistral could be implemented to improve resilience against outages or API failures.
+
+
 
-The service in charge of comunicating with WikiData will be coded using TypeSript. 
-As the generation of questions is a huge part of our application we will play it safe by using TypeSript, a language that is similar to JavaSript but with static type checking.
 
-*03/02/2025*
+[[ADR-010]]
+=== ADR 010: Monitoring Strategy   ******************************************************************************
+*Status: Accepted*
+*:date: 28/04/2025* 
 
-Microservices Architecture:
-The application will follow a Microservices architecture to ensure scalability, flexibility, and easier maintenance. This approach allows different services to be developed, deployed, and scaled independently, improving fault tolerance and facilitating continuous deployment.
+==== Context
 
-WikiData Service - TypeScript:
-The service responsible for communicating with WikiData will be developed using TypeScript. Since generating questions is a critical part of our application, we decided to use TypeScript due to its static type checking, which helps prevent runtime errors and makes the codebase more maintainable. Additionally, TypeScript provides better tooling support and improves developer productivity by reducing debugging time.
 
-Backend & Frontend Technologies:
-The backend will be built using Node.js, as it is efficient for handling asynchronous operations and provides a vast ecosystem of libraries.
-The frontend will be developed with React, a popular JavaScript library known for its component-based structure, performance optimizations, and reusability. React's virtual DOM improves rendering efficiency, making it a great choice for dynamic applications.
+==== Decision
 
-Database - MongoDB:
-We have chosen MongoDB, a NoSQL database, because it provides flexibility in handling unstructured data, horizontal scalability, and high availability. Given that our data structure may evolve over time, MongoDB’s schema-less nature allows us to adapt without complex migrations.
 
-Deployment Strategy:
-The application will be deployed on a server owned by one of the team members. This decision allows us to have full control over the deployment environment, reduce costs, and customize configurations based on our needs.
 
-*03/03/2025*
+==== Reasoning
 
-Switching from TypeScript to JavaScript:
-We initially opted for TypeScript to improve code quality through static typing. However, after encountering integration issues, increased complexity, and longer development time, we decided to switch to JavaScript. JavaScript allows for faster iteration, broader community support, and reduced setup overhead, making it more practical for our project timeline.
+* Prometheus + Grafana
+* Oracle Cloud Monitoring
path: docs/src/09_architecture_decisions.adoc
user: login: LucasGisb
body: Ok
created_at: 2025-05-02T20:47:51Z
author_association: NONE
diff_hunk: @@ -1,44 +1,374 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Database:* MongoDB (see <<ADR-002>>)
+* *Deployment:* Docker
+
+==== Reasoning
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Reasoning
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+*Status: Proposed and Rejected*
+*:date: 16/03/2025* 
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Reasoning
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript. JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+*Status: Accepted*
+*:date: 16/03/2025* 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Reasoning
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle Cloud VM for Deployment Infrastructure
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+The application required a virtualized environment to deploy the frontend, backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and having almost every member of the team some level of experince, thanks to having used it in other subjects.
+
+However, during early planning, one team member already had access to an Oracle Cloud VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle Cloud VM instance to host the project infrastructure.
+
+==== Reasoning
+
+* Immediate availability of an Oracle Cloud VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+* With Oracle Cloud VM we can have the aplicattion deployed 24/7.
+* In case anyone have to do any kind of work on the VM, giving access to it is simple because only SSH and the IP are required.
path: docs/src/09_architecture_decisions.adoc
user: login: LucasGisb
body: Ok
created_at: 2025-05-02T20:50:13Z
author_association: NONE
diff_hunk: @@ -1,44 +1,374 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-design-decisions]]
+
 == Architecture Decisions
 
-The application will be carried out following a Microservices architecture. +
+[[ADR-001]]
+=== ADR 001: Key Initial Architecture Decisions
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+At the very beginning of the project, it was necessary to establish a strong technological foundation. 
+These initial decisions were made based on team expertise, project requirements, and the need for scalability, maintainability, and efficient development practices.
+
+==== Decision
+
+The following initial architectural decisions were made:
+
+* *Frontend:* React
+* *Backend:* JavaScript with Node.js  (see <<ADR-003>>)
+* *Database:* MongoDB (see <<ADR-002>>)
+* *Deployment:* Docker
+
+==== Reasoning
+
+* *React* provides a robust, component-based framework ideal for building dynamic and scalable user interfaces.
+* *JavaScript/Node.js* ensures full-stack JavaScript development, simplifying the technology stack and improving development efficiency.
+* *Docker* offers containerization, enabling consistent deployment across different environments and simplifying the CI/CD process.
+
+==== Consequences
+
+* Unified technology stack using JavaScript for both frontend and backend.
+* Simplified developer onboarding and cross-functional collaboration.
+* Easier scaling and deployment of applications thanks to containerization.
+* Requires team members to be familiar with Docker and container management best practices.
+
+
+
+[[ADR-002]]
+=== ADR 002: Database Choice - MongoDB
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+A flexible, scalable database was needed to manage our data efficiently. 
+The project demands agility to handle evolving data structures, rapid development, and scalability.
+
+==== Decision
+
+MongoDB was chosen as the primary database.
+
+==== Reasoning
+
+* Document-based model suits the dynamic nature of the data.
+* High scalability and replication features out-of-the-box.
+* Wide developer familiarity and strong community support.
+* Flexible schema design allows for rapid iteration and prototyping.
+
+==== Alternatives considered
+
+*Relational Databases (e.g., PostgreSQL, MySQL)*
+
+* Pros:
+  ** Strong data integrity with ACID transactions.
+  ** Mature ecosystem, rich tooling, and widespread knowledge.
+  ** Powerful querying capabilities with SQL.
+* Cons:
+  ** Rigid schemas could slow down development during early, rapidly changing phases.
+  ** Higher initial overhead in schema design and migrations.
+  ** Potential impedance mismatch when handling unstructured or flexible data.
+
+==== Consequences
+
+* Simplified data modeling suited for flexible and evolving requirements.
+* Need for developers to understand and handle eventual consistency patterns.
+* Potential trade-offs in transactional guarantees compared to traditional relational databases.
+
+
+
+
+
+[[ADR-003]]
+=== ADR 003: Adoption of TypeScript and Tailwind CSS  
+*Status: Proposed and Rejected*
+*:date: 16/03/2025* 
+
+==== Context
+
+At the beginning of the project, we considered adopting TypeScript as the main programming language. 
+The integration with JavaScript would allow us to leverage static typing, improve code readability, and enhance maintainability.
+Additionally, we planned to combine TypeScript with Tailwind CSS for styling frontend components, aiming for a consistent and rapid UI development process.
+
+==== Decision
+
+Ultimately, the decision to adopt TypeScript and Tailwind was rejected.
+The project continued using JavaScript as the primary development language.
+
+==== Reasoning
+
+* TypeScript offered significant advantages in terms of type safety, better tooling, and enhanced code quality.
+* Tailwind CSS promised faster and more consistent frontend development.
+* However, serious compatibility issues arose with the project's foundational base and its critical dependencies when integrating TypeScript. JavaScript, on the other hand, ensured full compatibility with existing dependencies and leveraged the team's strong prior experience.
+
+==== Alternatives considered
+
+* Continue using **JavaScript**:
+  ** Pros:
+     *** Full compatibility with existing project dependencies.
+     *** Immediate development without additional configuration overhead.
+     *** Team proficiency already high.
+  ** Cons:
+     *** Lack of static typing, increasing potential runtime errors.
+     *** Slightly lower long-term maintainability compared to TypeScript.
+
+==== Consequences
+
+* Development continued smoothly without facing critical integration issues.
+* Future migration to TypeScript remains a possibility, but would require significant planning and dependency refactoring.
+* Styling strategies were adjusted, favoring traditional CSS Modules instead of Tailwind CSS for frontend components.
+
+
+
+
+[[ADR-004]]
+=== ADR 004: Wikidata SPARQL Integration
+*Status: Accepted*
+*:date: 16/03/2025* 
+
+==== Context
+
+The application requires retrieving rich, structured information from Wikidata to answer user questions and enrich the user experience with semantic data.
+Given the complexity of the data relationships and the dynamic nature of the content, a robust and standardized query mechanism was needed.
+
+==== Decision
+
+SPARQL was adopted as the primary method for querying Wikidata.
+
+==== Reasoning
+
+* SPARQL is the native query language for RDF datasets like Wikidata.
+* It allows highly expressive queries involving relationships between entities, filters, and complex graph traversals.
+* Wikidata provides a public SPARQL endpoint (Wikidata Query Service), eliminating the need to host or maintain a local copy of the dataset.
+* Supports real-time access to the most up-to-date knowledge base.
+
+==== Consequences
+
+* Enables powerful and flexible data retrieval directly from Wikidata.
+* Introduces a dependency on the availability and performance of the public SPARQL endpoint.
+* Requires developers to learn and work with SPARQL syntax and semantic web concepts.
+* May necessitate caching strategies or fallback plans to mitigate latency or downtime.
+
+
+
+
+[[ADR-005]]
+=== ADR 005: Oracle Cloud VM for Deployment Infrastructure
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+The application required a virtualized environment to deploy the frontend, backend services, the database, and monitoring tools. Initially, Microsoft Azure was considered as the deployment platform due to its popularity and having almost every member of the team some level of experince, thanks to having used it in other subjects.
+
+However, during early planning, one team member already had access to an Oracle Cloud VM instance that was partially configured and available for use. This presented an opportunity to streamline deployment efforts and reduce setup time and cost.
+
+==== Decision
+
+The team decided to use an Oracle Cloud VM instance to host the project infrastructure.
+
+==== Reasoning
+
+* Immediate availability of an Oracle Cloud VM already partially configured.
+* Team member already had experience managing this VM, including port configuration and service setup.
+* Avoids incurring additional cloud infrastructure costs.
+* Simplifies initial deployment and testing.
+* With Oracle Cloud VM we can have the aplicattion deployed 24/7.
+* In case anyone have to do any kind of work on the VM, giving access to it is simple because only SSH and the IP are required.
+
+==== Alternatives considered
+
+*Azure Virtual Machines (Microsoft Azure)*
+
+** Pros:
+  *** Well-documented and widely adopted cloud platform.
+  *** Integrated monitoring, CI/CD tools, and scalability features.
+  *** Easier to integrate with enterprise authentication or other Azure-based services.
+** Cons:
+  *** Requires account setup, configuration, and billing.
+  *** Team would need time to familiarize with the environment.
+  *** No immediate advantage over the already available Oracle VM at this stage.
+  *** In case we have used Azure, we would be obligated to turn on and off the application whenever it is necessary.
+
+==== Consequences
+
+* Faster initial deployment due to use of an already prepared environment.
+* Reduced cloud infrastructure cost during the development.
+* May require future migration or scaling strategy if the project grows or if Oracle Cloud VM limitations become restrictive.
+
+
+
+[[ADR-006]]
+=== ADR 006: Service-based System Architecture
+*Status: Accepted*
+*:date: 23/02/2025* 
+
+==== Context
+
+In designing the backend system, the team considered different architectural styles to support modularity, maintainability, and scalability.
+A pure microservices architecture was initially discussed and followed due to its popularity and the main project was built in a microservice based architecture.
+However, during the development of the application, a service-based architecture was chosen instead.
+
+==== Decision
+
+The project adopts a service-based architecture, rather than a fully decoupled microservices model.
+
+==== Reasoning
+
+* Provides modularization and separation of concerns without the overhead of managing independent deployments for each service.
+* Simplifies inter-service communication by avoiding complex patterns such as service discovery, load balancing, and distributed configuration.
+* Better aligns with the existing project base and team size, facilitating easier maintenance and deployment.
+* Reduces initial development and operational complexity.
+
+==== Alternatives considered
+
+*Pure Microservices Architecture*
+
+** Pros:
+  *** Strong decoupling, allowing for independent scaling and deployment of services.
+** Cons:
+  *** Overkill for small or medium-sized teams and projects with limited domain boundaries.
+
+==== Consequences
+
+* Enables a modular structure where services are separated logically but may coexist within the application itself.
+* Facilitates faster development and easier testing.
+* Allows future evolution toward microservices if project requirements grow.
+
+
+
+[[ADR-007]]
+=== ADR 007: Data Storage for Wikidata Information
+*Status: Accepted*
+*:date: 16/03/2025* 
+
+==== Context
+
+Initially, the application fetched data from Wikidata in real time during gameplay to generate questions dynamically.
+However, this approach caused severe performance issues, resulting in noticeable delays that degraded the user experience during matches.
+
+==== Decision
+
+To improve performance, the application now pre-generates and stores a set of questions in the database at the start of each game.
+These stored questions are then served to the user dynamically throughout the match, minimizing latency.
+
+==== Reasoning
+
+* Real-time queries to Wikidata introduced unpredictable delays and negatively impacted gameplay flow.
+* Preloading questions ensures smooth and uninterrupted user experience.
+* Reduces dependency on external services during active sessions, making the game more stable and reliable.
+
+==== Alternatives considered
+
+*Inserting loading screens between questions*
+
+** Pros:
+  *** Would allow real-time querying to continue without significant architectural changes.
+  *** Could be visually appealing with the right UI/UX design.
+** Cons:
+  *** Did not solve the root performance issue — only masked it.
+  *** Introduced unwanted pauses that disrupted the game's pacing and fluidity.
+
+==== Consequences
+
+* Game sessions begin with a brief setup phase where questions are fetched and stored.
+* Once the session starts, question delivery is fast and reliable, improving overall experience.
+* The system is now more resilient to outages or slowdowns in the Wikidata SPARQL endpoint.
+
+
+
+[[ADR-008]]
+=== ADR 008: Styling Approach - CSS Modules
+*Status: Accepted*
+*:date: 16/03/2025* 
+
+==== Context
+
+Maintaining scoped styles without introducing unnecessary complexity.
+
+==== Decision
+
+Use CSS Modules for styling, with partial hybridization where needed.
+
+==== Reasoning
+
+* Keeps styles encapsulated.
+* Allows flexibility where global styles are needed.
+
+==== Consequences
+
+* Mixed styling approach may introduce slight overhead.
+
+
+[[ADR-009]]
+=== ADR 009: Choice of Empathy LLM
+*Status: Accepted*
+*:date: 07/04/2025* 
+
+==== Context
+
+To implement the chatbot system that provides hints during gameplay, the project required integration with a Large Language Model (LLM). The main criteria were accuracy, responsiveness, and a reduced tendency toward hallucination or incorrect answers, as the quality of hints directly affects user experience.
+
+==== Decision
+
+The team chose to use the Qwen2.5-Coder-7B-Instruct model provided through the Empathy LLM platform.
+
+==== Reasoning
+
+* Empathy LLM provided an API key with access to two models:
+  ** Mistral-7B-Instruct-v0.3
+  ** Qwen2.5-Coder-7B-Instruct
+* After testing both models, Qwen was selected for:
+  ** Higher consistency in structured, instructional outputs.
+  ** Better handling of technical prompts and explanation-style hints.
+  ** More stable performance with fewer hallucinations under our prompt style.
+* The Empathy API offered fast response times and easy integration, allowing for rapid prototyping and feedback iteration.
+
+==== Alternatives considered
+
+*Mistral-7B-Instruct-v0.3*
+
+** Pros:
+  *** Well-known model with good general performance.
+  *** Slightly faster in some shorter prompts.
+** Cons:
+  *** More prone to generating vague or verbose responses in our use case.
+  *** Occasionally less precise in multi-turn or guided question scenarios.
+
+==== Consequences
+
+* The chatbot feature benefits from a lightweight, instruction-tuned LLM tailored to the task.
+* Reduces hallucination risk, improving player trust in hints.
+* The choice of Qwen may require future fine-tuning or prompt engineering as feature complexity grows.
+* Integration is dependent on the continued availability and performance of the Empathy LLM platform.
+* In the future, a fallback strategy using both Qwen and Mistral could be implemented to improve resilience against outages or API failures.
+
+
 
-The service in charge of comunicating with WikiData will be coded using TypeSript. 
-As the generation of questions is a huge part of our application we will play it safe by using TypeSript, a language that is similar to JavaSript but with static type checking.
 
-*03/02/2025*
+[[ADR-010]]
+=== ADR 010: Monitoring Strategy   ******************************************************************************
+*Status: Accepted*
+*:date: 28/04/2025* 
 
-Microservices Architecture:
-The application will follow a Microservices architecture to ensure scalability, flexibility, and easier maintenance. This approach allows different services to be developed, deployed, and scaled independently, improving fault tolerance and facilitating continuous deployment.
+==== Context
 
-WikiData Service - TypeScript:
-The service responsible for communicating with WikiData will be developed using TypeScript. Since generating questions is a critical part of our application, we decided to use TypeScript due to its static type checking, which helps prevent runtime errors and makes the codebase more maintainable. Additionally, TypeScript provides better tooling support and improves developer productivity by reducing debugging time.
 
-Backend & Frontend Technologies:
-The backend will be built using Node.js, as it is efficient for handling asynchronous operations and provides a vast ecosystem of libraries.
-The frontend will be developed with React, a popular JavaScript library known for its component-based structure, performance optimizations, and reusability. React's virtual DOM improves rendering efficiency, making it a great choice for dynamic applications.
+==== Decision
 
-Database - MongoDB:
-We have chosen MongoDB, a NoSQL database, because it provides flexibility in handling unstructured data, horizontal scalability, and high availability. Given that our data structure may evolve over time, MongoDB’s schema-less nature allows us to adapt without complex migrations.
 
-Deployment Strategy:
-The application will be deployed on a server owned by one of the team members. This decision allows us to have full control over the deployment environment, reduce costs, and customize configurations based on our needs.
 
-*03/03/2025*
+==== Reasoning
 
-Switching from TypeScript to JavaScript:
-We initially opted for TypeScript to improve code quality through static typing. However, after encountering integration issues, increased complexity, and longer development time, we decided to switch to JavaScript. JavaScript allows for faster iteration, broader community support, and reduced setup overhead, making it more practical for our project timeline.
+* Prometheus + Grafana
+* Oracle Cloud Monitoring
 
-CSS Modules for Styling:
-We have chosen to use CSS Modules for styling because it:
+==== Consequences
 
-Prevents style conflicts by scoping styles to individual components.
-Improves maintainability by keeping styles modular and easy to manage.
-Enhances reusability as styles are encapsulated within their respective components, reducing the risk of unintended global overrides.
 
-These decisions were made to optimize performance, maintainability, and scalability while ensuring smooth development and deployment of our application.
 
path: docs/src/09_architecture_decisions.adoc
user: login: LucasGisb
body: Ok
created_at: 2025-05-02T20:51:05Z
author_association: NONE
diff_hunk: @@ -57,47 +57,59 @@ See https://docs.arc42.org/section-8/[Concepts] in the arc42 documentation.
 ****
 endif::arc42help[]
 
-=== _Continuous integration and development_
+=== _Domain concepts_
 
+|===
+| *Class* | *Explanation*
+| User | The people using the application, playing matches and generating statistics of their own.
+| Statistics | Given the performance of the player in its matches, relevant information is stored.
+| Match | Created when the user starts a game and includes its general information and generated questions.
+| Question | Questions spawned in a match, storing all its answers.
+| Answer | Every answer associated to a match's question, saving if it was the correct option and if was selected by the player.
+|===
+image:08-domainModel.png["Concepts - Domain Model"]
+
+
+=== _"Under-the-hood"_
+
+* *Backend*:  
+  The server-side logic of the application is implemented using Node.js in combination with the Express framework. The backend handles client requests, communicates with external services such as Wikidata and Empathy, manages user sessions, interacts with the database and other functionalities.
+
+* *Frontend*:  
+  The frontend is developed using React, a component-based JavaScript library that enables the creation of dynamic and interactive user interfaces. The frontend is responsible for rendering the game interface, managing user input, and presenting questions, hints, and scores.
+
+* *Database and persistence*:  
+  MongoDB serves as the main data store, offering a flexible document-oriented model that aligns well with the evolving structure of game data. It stores user profiles, game progress, generated questions, and historical results in JSON-like documents.
+
+* *LLM Integration*:  
+  We utilize Empathy, a Large Language Model (LLM), to enhance the gameplay experience by generating intelligent and context-aware hints for each question in real time.
+
+* *External Data Source*:  
+  To keep the game content rich and dynamic, we integrate Wikidata as our primary external knowledge source. Through its public REST API, we query up-to-date and structured information about a wide range of topics. This enables automatic generation of questions based on real-world data.
+
+
+
+=== _Development concepts_
+* *Continuous integration and development*
 Our way of working with github is having one developing branch towards which all pull requests are done 
 and have to be reviewed by at least one team member. 
 Sonar Cloud is set up so we know the testing coverage and whether we pass the quality gate with every pull request.
 Once there is enough change in the develop branch with respect to the main one and it has enough quality we can 
 merge them and make a release.
 
+* *Testings*
+One of the most important aspects is testing our application, and to achieve this, we will conduct different types of tests. On one hand, we will perform tests such as unit testing and usability testing. On the other hand, we will implement a continuous testing system using GitHub Actions, ensuring that all commits pass the required tests.
 
-=== _Microservice based system_
-
-Different business functionallities will be developed in different independent services.
-This will ensure that if one of them fails, the rest are still working (For example,
-if the rankings go down that will not affect the main game) as they have their own deployment
-as well. 
-Other benefits are increased maintainability due to separation in small, more readable modules
-and the possibillity of using different languages or technologies for each module if needed/prefered 
-without colliding with the rest.
-
-
-=== _Gateway service routing_
-
+=== _Operational concepts_
+* *Gateway service routing*
 We will use a speciallized service that will route the requests to the corresponding service, acting as 
 a single entry point for the application. Requests to the services are much simpler as only the api base 
 endpoint and the action needs to be known and the gateway can also act as a filter to manage requests 
 conditionally if needed. This approach also favors security as we can control which requests are actually 
 sent based on its content or the context of the app.
 
-=== _Authentication_
-
-To keep our users' data secure an authentication mechanism has been developed with the use of JSON Web Tokens (JWT). If someone tries to access historical game records for certain users, our KaW application enforces to pass a valid token through the header of the message request.
-In this way, only authenticated users are able to consult the different data that our application enforces.
+=== _Safety and security concepts_
 
-=== _Internationalization_ 
+* *Secure storage*
+User passwords are never stored in plain text. Instead, secure hashing algorithms and encryption techniques are employed to protect sensitive information and prevent unauthorized access.
 
path: docs/src/08_concepts.adoc
user: login: LucasGisb
body: Ok my bullet friend
created_at: 2025-05-02T20:56:12Z
author_association: NONE
diff_hunk: @@ -57,47 +57,59 @@ See https://docs.arc42.org/section-8/[Concepts] in the arc42 documentation.
 ****
 endif::arc42help[]
 
-=== _Continuous integration and development_
+=== _Domain concepts_
 
+|===
+| *Class* | *Explanation*
+| User | The people using the application, playing matches and generating statistics of their own.
+| Statistics | Given the performance of the player in its matches, relevant information is stored.
+| Match | Created when the user starts a game and includes its general information and generated questions.
+| Question | Questions spawned in a match, storing all its answers.
+| Answer | Every answer associated to a match's question, saving if it was the correct option and if was selected by the player.
+|===
+image:08-domainModel.png["Concepts - Domain Model"]
+
+
+=== _"Under-the-hood"_
path: docs/src/08_concepts.adoc
user: login: LucasGisb
body: Dont thinks so
created_at: 2025-05-02T20:56:43Z
author_association: NONE
diff_hunk: @@ -57,47 +57,59 @@ See https://docs.arc42.org/section-8/[Concepts] in the arc42 documentation.
 ****
 endif::arc42help[]
 
-=== _Continuous integration and development_
+=== _Domain concepts_
 
+|===
+| *Class* | *Explanation*
+| User | The people using the application, playing matches and generating statistics of their own.
+| Statistics | Given the performance of the player in its matches, relevant information is stored.
+| Match | Created when the user starts a game and includes its general information and generated questions.
+| Question | Questions spawned in a match, storing all its answers.
+| Answer | Every answer associated to a match's question, saving if it was the correct option and if was selected by the player.
+|===
+image:08-domainModel.png["Concepts - Domain Model"]
+
+
+=== _"Under-the-hood"_
+
+* *Backend*:  
+  The server-side logic of the application is implemented using Node.js in combination with the Express framework. The backend handles client requests, communicates with external services such as Wikidata and Empathy, manages user sessions, interacts with the database and other functionalities.
+
+* *Frontend*:  
+  The frontend is developed using React, a component-based JavaScript library that enables the creation of dynamic and interactive user interfaces. The frontend is responsible for rendering the game interface, managing user input, and presenting questions, hints, and scores.
+
+* *Database and persistence*:  
+  MongoDB serves as the main data store, offering a flexible document-oriented model that aligns well with the evolving structure of game data. It stores user profiles, game progress, generated questions, and historical results in JSON-like documents.
+
+* *LLM Integration*:  
+  We utilize Empathy, a Large Language Model (LLM), to enhance the gameplay experience by generating intelligent and context-aware hints for each question in real time.
+
+* *External Data Source*:  
+  To keep the game content rich and dynamic, we integrate Wikidata as our primary external knowledge source. Through its public REST API, we query up-to-date and structured information about a wide range of topics. This enables automatic generation of questions based on real-world data.
+
+
+
+=== _Development concepts_
path: docs/src/08_concepts.adoc
user: login: LucasGisb
body: Ok
created_at: 2025-05-02T20:56:56Z
author_association: NONE
diff_hunk: @@ -22,10 +22,40 @@ image:06-login.png["Runtime view - Logging in"]
 
 When it comes to logging in, the user firstly enters their credentials, then the back end retrieves the user's information from the database and verifies if it's correct.
 
-=== Future diagrams
 
-Once we have made progress in the development of the application, the following diagrams should be created according to the chosen implementation:
+=== Questions generation
+&nbsp;
+
+image:06-questionGeneration.png["Runtime view - Question generation"]
+
+&nbsp;
+
+The user accesses the game, selects its mode and difficulty, and the call is made. The backend is responsible for obtaining the questions (along with their images and answers) and transmitting them to the frontend.
+
+=== WiChat quiz game
+&nbsp;
+
+image:06-gameCycle.png["Runtime view - Game cycle"]
+
+&nbsp;
+
+
+The user enters the game, selects the mode and difficulty, and once the question is answered, the user begins the game, answering each question until the timer runs out, ending the game. After the game ends, and after the information has been saved, the user can replay the game or access other views.
+
+=== Obtaining hints via Chatbot
+&nbsp;
+
+image:06-chatBotFunctionality.png["Runtime view - Hints by chatbot"]
+
+&nbsp;
+
+In the Game view, the user types their questions into the Chatbot component, which are then sent to the LLM, where the prompt to be passed to the AI ​​is configured and the response is generated, which is then returned to the frontend for the user to view.
+
+=== Leaderboard and match search
+&nbsp;
+
+image:06-leaderboardAndSearch.png["Runtime view - Leaderboard and match search"]
+
+&nbsp;
 
-==== Questions generation
-==== WiChat quiz game
-==== Obtaining hints via Chatbot
+The user accesses the Leaderboard, and on the one hand, data related to rankings and users is loaded, and on the other, the user can search for games by typing the name in the search input.
path: docs/src/06_runtime_view.adoc
user: login: LucasGisb
body: Yeah okey
created_at: 2025-05-02T21:00:33Z
author_association: NONE

PR comments:
user: login: netlify[bot]
created_at: 2025-04-29T12:06:56Z
body: ### <span aria-hidden="true">✅</span> Deploy Preview for *chipper-croquembouche-54cf79* ready!


|  Name | Link |
|:-:|------------------------|
|<span aria-hidden="true">🔨</span> Latest commit | ffc0cb76e88251a489c149d6071b79339a1637fa |
|<span aria-hidden="true">🔍</span> Latest deploy log | https://app.netlify.com/sites/chipper-croquembouche-54cf79/deploys/68154223d8d5f80008ffb91f |
|<span aria-hidden="true">😎</span> Deploy Preview | [https://deploy-preview-155--chipper-croquembouche-54cf79.netlify.app](https://deploy-preview-155--chipper-croquembouche-54cf79.netlify.app) |
|<span aria-hidden="true">📱</span> Preview on mobile | <details><summary> Toggle QR Code... </summary><br /><br />![QR Code](https://app.netlify.com/qr-code/eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1cmwiOiJodHRwczovL2RlcGxveS1wcmV2aWV3LTE1NS0tY2hpcHBlci1jcm9xdWVtYm91Y2hlLTU0Y2Y3OS5uZXRsaWZ5LmFwcCJ9.7tZTKHWts79hPqn6AC0w9lVOv_9ycxGqzn0nbfBUlYU)<br /><br />_Use your smartphone camera to open QR code link._</details> |
---
<!-- [chipper-croquembouche-54cf79 Preview](https://deploy-preview-155--chipper-croquembouche-54cf79.netlify.app) -->
_To edit notification comments on pull requests, go to your [Netlify site configuration](https://app.netlify.com/sites/chipper-croquembouche-54cf79/configuration/notifications#deploy-webhooks)._
author_association: NONE
user: login: sonarqubecloud[bot]
created_at: 2025-05-02T22:15:00Z
body: ## [![Quality Gate Passed](https://sonarsource.github.io/sonarcloud-github-static-resources/v2/checks/QualityGateBadge/qg-passed-20px.png 'Quality Gate Passed')](https://sonarcloud.io/dashboard?id=Arquisoft_wichat_es2c&pullRequest=155) **Quality Gate passed**  
Issues  
![](https://sonarsource.github.io/sonarcloud-github-static-resources/v2/common/passed-16px.png '') [0 New issues](https://sonarcloud.io/project/issues?id=Arquisoft_wichat_es2c&pullRequest=155&issueStatuses=OPEN,CONFIRMED&sinceLeakPeriod=true)  
![](https://sonarsource.github.io/sonarcloud-github-static-resources/v2/common/accepted-16px.png '') [0 Accepted issues](https://sonarcloud.io/project/issues?id=Arquisoft_wichat_es2c&pullRequest=155&issueStatuses=ACCEPTED)

Measures  
![](https://sonarsource.github.io/sonarcloud-github-static-resources/v2/common/passed-16px.png '') [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=Arquisoft_wichat_es2c&pullRequest=155&issueStatuses=OPEN,CONFIRMED&sinceLeakPeriod=true)  
![](https://sonarsource.github.io/sonarcloud-github-static-resources/v2/common/passed-16px.png '') [0.0% Coverage on New Code](https://sonarcloud.io/component_measures?id=Arquisoft_wichat_es2c&pullRequest=155&metric=new_coverage&view=list)  
![](https://sonarsource.github.io/sonarcloud-github-static-resources/v2/common/passed-16px.png '') [0.0% Duplication on New Code](https://sonarcloud.io/component_measures?id=Arquisoft_wichat_es2c&pullRequest=155&metric=new_duplicated_lines_density&view=list)  
  
[See analysis details on SonarQube Cloud](https://sonarcloud.io/dashboard?id=Arquisoft_wichat_es2c&pullRequest=155)


author_association: NONE