Merge pull request #168 from Arquisoft/develop

Release for 3 delivery

docker-compose.yml

@@ -19,7 +19,7 @@ services:
     depends_on:
       - mongodb
     ports:
-      - "8002:8002"
+      - "8003:8003"
     networks:
       - mynetwork
     environment:
@@ -49,7 +49,7 @@ services:
     networks:
       - mynetwork
     environment:
-      USERS_SERVICE_URL: http://users:8002
+      USERS_SERVICE_URL: http://users:8003
       WIKIDATA_SERVICE_URL: http://wikidataservice:8001
 
   webapp:

docs/src/03_system_scope_and_context.adoc

@@ -81,7 +81,7 @@ together with a mapping table showing the relationships between channels and inp
 |===
 | **Component** | **Technologies Used**
 | Front-end      | HTML, CSS (Tailwind), JavaScript (React)
-| Back-end       | .NET/node.js, Wikidata's API
+| Back-end       | node.js (Express), Wikidata's API
 | Database  | MongoDB
 | Arquitechture | Microservices
 | Deployment and Maintenance | Docker

docs/src/04_solution_strategy.adoc

@@ -35,25 +35,27 @@ See https://docs.arc42.org/section-4/[Solution Strategy] in the arc42 documentat
 * *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.
     + *Express.js*: Express.js, often simply called Express, is a minimalist web application framework for Node.js. It simplifies the process of building web applications by providing a robust set of features, including middleware support, routing, and templating engines. Express is known for its flexibility, simplicity, and performance, making it a popular choice for developing web applications and APIs in Node.js.
-* *.NET*: versatile developer platform for creating web, mobile, desktop, and cloud applications. It supports multiple programming languages and provides a rich set of libraries and tools for building software solutions. With built-in support for creating APIs and consuming web services, .NET makes it simple to develop and integrate with backend systems and services.
 * *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. 
 * *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.
-* *Cucumber*: Testing tool that supports Behavior Driven Development (BDD) and allows us also to comply testability quality attribute.
 * *SonarCloud*: Cloud-based service provided by SonarSource, which offers continuous code quality analysis and automated code reviews for software development projects. It helps developers identify and fix bugs, security vulnerabilities, and code smells in their codebase to improve overall software quality.
 * *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.
 * *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.
 * *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.
+
+=== Technological decisions
+
+At the beggining of the project, the team decided to develop the wikidata API by means of .NET technology and C# programming language. 
+As part of continuous integration, the application was attempted to be deployed without success due to docker issues with .NET container. 
+Therefore, the team decided to migrate the whole API to Node.js using javascript and express framework.
+As a conclusion, it was worth spending time making the migration for reducing the number of potential issues at deployment time.
 
 === Architecture & Design
 
 * *Microservices*: is an architectural style that structures an application as a collection of loosely coupled services. Each service is independently deployable, scalable, and can be developed using different programming languages, frameworks, or databases.
 In a microservices architecture, each service typically represents a specific business function or capability and communicates with other services through well-defined APIs. This enables teams to work independently on different parts of the application, allowing us to divide the work into different teams avoiding bottlenecks during production.
 * *APIs*: using microservices architecture enforces us to isolate each of the microservices and create well-defined interfaces for accesing those microservices from common gateway, reducing dependencies between services and allowing them to evolve independently. Well-defined interfaces imply not only services independance, but also team members independecance since nobody will need to wait for others for starting working themselves.  
 
---------------------(This could be another option if we eventually decide not to use microservices architecture)--------------------
-
-* *MVC (Model-View-Controller)*: is a software architectural pattern which divides an application into three interconnected components: the Model, which represents the data and business logic; the View, responsible for the presentation layer and user interface; and the Controller, acting as an intermediary between the Model and View. MVC promotes separation of concerns, making it easier to manage and maintain complex web applications by enabling developers to work on different components independently. This pattern enhances code reuse, improves testability, and facilitates scalability, contributing to the development of robust and maintainable web applications across various frameworks and programming languages.
-
 === Team Organization
 
 For developing this project we are using Github as the control version systems. 

docs/src/05_building_block_view.adoc

@@ -99,74 +99,6 @@ Contained Building Blocks::
 |===
 
 
-[role="arc42help"]
-****
-Insert your explanations of black boxes from level 1:
-
-If you use tabular form you will only describe your black boxes with name and
-responsibility according to the following schema:
-
-[cols="1,2" options="header"]
-|===
-| **Name** | **Responsibility**
-| _<black box 1>_ | _<Text>_
-| _<black box 2>_ | _<Text>_
-|===
-
-
-
-If you use a list of black box descriptions then you fill in a separate black box template for every important building block .
-Its headline is the name of the black box.
-****
-
-
-==== <Name black box 1>
-
-[role="arc42help"]
-****
-Here you describe <black box 1>
-according the the following black box template:
-
-* Purpose/Responsibility
-* Interface(s), when they are not extracted as separate paragraphs. This interfaces may include qualities and performance characteristics.
-* (Optional) Quality-/Performance characteristics of the black box, e.g.availability, run time behavior, ....
-* (Optional) directory/file location
-* (Optional) Fulfilled requirements (if you need traceability to requirements).
-* (Optional) Open issues/problems/risks
-
-
-
-_<Purpose/Responsibility>_
-
-_<Interface(s)>_
-
-_<(Optional) Quality/Performance Characteristics>_
-
-_<(Optional) Directory/File Location>_
-
-_<(Optional) Fulfilled Requirements>_
-
-_<(optional) Open Issues/Problems/Risks>_
-
-
-
-
-==== <Name black box 2>
-
-_<black box template>_
-
-==== <Name black box n>
-
-_<black box template>_
-
-
-==== <Name interface 1>
-
-...
-
-==== <Name interface m>
-****
-
 === Level 1
 
 [role="arc42help"]
@@ -185,14 +117,16 @@ actor user as "User browser"
 frame WIQ {
     node Frontend
     node UserManagement
-    node QuestionGeneration
+    node WikidataService
+    node Gateway
 }
 cloud Wikidata as "Wikidata"
 
 user -- Frontend
-Frontend -- UserManagement
-Frontend -- QuestionGeneration
-QuestionGeneration -- Wikidata
+Frontend -- Gateway
+Gateway -- UserManagement
+Gateway -- WikidataService
+WikidataService -- Wikidata
 ....
 
 
@@ -209,17 +143,18 @@ Contained Building Blocks::
 | **Name** | **Responsibility**
 | Frontend  | Represents the user interface and manages the quiz logic of the application.
 | User Management | Handles everything related to user accounts.
-| Question Generator | Generates questions from Wikidata data and sends them to the frontend.
+| Wikidata Service | Generates questions from Wikidata data.
+| Gateway |Acts as a central hub for managing API traffic.
 |===
 
 Important Interfaces::
 
 [cols="1,2" options="header"]
 |===
 | **Name** | **Description**
-| Frontend <-> User Management  | This interface defines how the frontend communicates with the User Management Service to log in, retrieve user data, or perform actions requiring authorization.
-| Question Generator <-> Frontend | This interface defines how the Question Generator Service delivers processed questions to the frontend for display.
-| Question Generator <-> Wikidata API | This interface represents the service fetching data from the Wikidata API.
+| Frontend -> User Management  | This interface defines how the frontend communicates with the User Management Service to log in, retrieve user data, or perform actions requiring authorization.
+| Frontend -> Wikidata Service | This interface defines how the Question Generator Service delivers processed questions to the frontend for display.
+| Wikidata Service -> Wikidata API | This interface represents the service fetching data from the Wikidata API.
 |===
 
 
@@ -244,8 +179,6 @@ Its headline is the name of the black box.
 ****
 
 
-==== <Name black box 1>
-
 [role="arc42help"]
 ****
 Here you describe <black box 1>
@@ -317,7 +250,7 @@ Leave out normal, simple, boring or standardized parts of your system
 skinparam componentStyle uml2
 
 ' Define components as rectangles without default stereotypes
-rectangle "User Management" as UserManagement
+rectangle "User Management API" as UserManagement
 database "Users MongoDB Database" as MongoDB
 
 ' Define connections
@@ -326,7 +259,7 @@ UserManagement --> MongoDB
 @enduml
 ----
 
-==== White Box Question Generation Service
+==== White Box Wikidata Service
 
 
 [role="arc42help"]
@@ -341,45 +274,35 @@ UserManagement --> MongoDB
 skinparam componentStyle uml2
 
 ' Define components as rectangles without default stereotypes
-rectangle "Question Generation" as QuestionGeneration
-database "Questions MongoDB Database" as MongoDB
+rectangle "Wikidata Service API" as WikidataService
 cloud "Wikidata API" as WikidataAPI
 
 ' Define connections
-QuestionGeneration --> MongoDB
-QuestionGeneration --> WikidataAPI
+WikidataService --> WikidataAPI
 @enduml
 ----
 
 
 === Level 3
 
-[role="arc42help"]
-****
-Here you can specify the inner structure of (some) building blocks from level 2 as white boxes.
-
-When you need more detailed levels of your architecture please copy this
-part of arc42 for additional levels.
-****
-
+==== White Box User Management API
 
-==== White Box <_building block x.1_>
 
 [role="arc42help"]
 ****
-Specifies the internal structure of _building block x.1_.
+...describes the internal structure of the User Management API.
 ****
 
+[plantuml, format=png]
+....
+frame UserManagementAPI {
+    node UserService
+    node AuthService
+}
+database MongoDB as "MongoDB"
 
-_<white box template>_
-
-
-==== White Box <_building block x.2_>
-
-_<white box template>_
-
-
+UserService -- MongoDB
+AuthService -- MongoDB
+....
 
-==== White Box <_building block y.1_>
 
-_<white box template>_

docs/src/06_runtime_view.adoc

@@ -16,10 +16,10 @@ collections UsersService
 database DB
 
 User -> FrontEnd: Request login
-FrontEnd -> UsersService: loginUser()
-UsersService  -> DB: checkUserData()
+FrontEnd -> UsersService: "/users/login"
+UsersService  -> DB: validateRequiredFields()
 DB -> UsersService: Confirm data
-UsersService -> UsersService: login()
+UsersService -> UsersService: loginUser()
 UsersService -> FrontEnd: Confirm login
 ----
 
@@ -35,12 +35,11 @@ collections UsersService
 database DB
 
 User -> FrontEnd: Request sign up
-FrontEnd -> UsersService: registerUser()
+FrontEnd -> UsersService: "/users/adduser"
 UsersService -> DB: checkCredentialsExist()
 DB -> UsersService: Confirm data
-UsersService  -> DB: CreateUserData()
+UsersService  -> DB: Create new user
 DB -> UsersService: Confirm data
-UsersService -> UsersService: signUp()
 UsersService -> FrontEnd: Redirect to login page
 @enduml
 ----
@@ -53,18 +52,15 @@ Sequence diagram for the process of retrieving data from WikiData
 ----
 actor User
 collections FrontEnd
-collections QuestionGenerator
+collections WikidataService
 database Wikidata
 
-User -> FrontEnd: Request a game
-FrontEnd -> QuestionGenerator: createGame()
-QuestionGenerator-> Wikidata: Sparql query
-Wikidata-> QuestionGenerator : entitites data
-QuestionGenerator-> QuestionGenerator: fillQuestionStack()
-QuestionGenerator-> QuestionGenerator: popGameQuestions()
-QuestionGenerator-> FrontEnd: Send game
+User -> FrontEnd: Start Game
+FrontEnd -> WikidataService: "/GetQuestions"
+WikidataService-> Wikidata: Sparql query
+Wikidata-> WikidataService : entitites data
+WikidataService-> WikidataService: createQuestions()
+WikidataService-> FrontEnd: Send 10 questions
 FrontEnd -> User: Question 1
 User-> FrontEnd: Answer 1
 ----
-
-=== <Runtime Scenario n>

docs/src/07_deployment_view.adoc

@@ -107,20 +107,24 @@ frame Azure {
                 node React
             }
 
-            frame NodeJSGateway {
-                node Authentication
-
+            frame APIGateway {
                 node Users
+
+                node Wikidata
             }
 
             database MongoDB {
                 node UsersDatabase
+            }
 
-                node ResultsDatabase
+            frame UsersAPI {
+                node AuthenticationService
+
+                node UsersService
             }
 
-            frame .NET {
-                node RestAPI
+            frame WikidataAPI {
+                node QuestionGeneratorService
             }
         }
     }
@@ -138,10 +142,11 @@ frame GitHub{
 
     }
 
-.NET -- ResultsDatabase : MongoDB (port 27017)
-NodeJSGateway -- UsersDatabase : MongoDB (port 27017)
-WebAPP -- NodeJSGateway : (port 8000:8002)
-WebAPP -- .NET : .NET (port TBD)
+
+WebAPP -- APIGateway : port 8000
+Wikidata -- WikidataAPI: port 8001
+Users -- UsersAPI : port 8002
+UsersAPI -- UsersDatabase : MongoDB (port 27017)
 client -- WebAPP : Web Browser (port 3000)
 
 GitHubActions -- UbuntuServer : on release
@@ -165,8 +170,9 @@ The virtual machine will contain as many containers as services in the applicati
 
 For now, the project contains:
 ** Web application service running on port 3000
-*** Gateway (middleware) service running on port 8000
-*** Users and authentication services running on ports 8001 and 8002 respectively
+** Gateway (middleware) service running on port 8000
+** Wikidata API running on port 8001
+** Users API running on port 8002
 ** Mongo DB server running on port 27017
 ** Prometheus running on port 9090 for monitoring
 ** Grafana running on port 9091 for analytics and monitoring