diff --git a/docs/images/3-TechnicalContext.drawio.svg b/docs/images/3-TechnicalContext.drawio.svg index b3226527..8f9a0078 100644 --- a/docs/images/3-TechnicalContext.drawio.svg +++ b/docs/images/3-TechnicalContext.drawio.svg @@ -1,4 +1,4 @@ -
User
User
WIQ























WIQ...
Database
Database
HTTPS
HTTPS
LOGIN AND AUTHENTICATION
LOGIN AND AUTHENTICA...
QUESTION GENERATION
QUESTION GENERATION
HOME
HOME
HTTPS
HTTPS
redirect
redirectText is not SVG - cannot display \ No newline at end of file +
User
WIQ























Users
Database
HTTP
LOGIN AND AUTHENTICATION
GAME
HOME
HTTP
redirect
QUESTION GENERATION
Database
loads questions
retrieve
questions
retrieve
records
 \ No newline at end of file diff --git a/docs/images/5-Level1.svg b/docs/images/5-Level1.svg index 58e7fca5..76109e3a 100644 --- a/docs/images/5-Level1.svg +++ b/docs/images/5-Level1.svg @@ -1,4 +1,4 @@ -
WIQ










Wikidata
User
HOME
USER MANAGEMENT
USER DB
QUESTION GAME
QUESTIONS DB
 \ No newline at end of file +
Actor
Wikidata
Gateway service
WIQ
Webapp
WIQ
Services
 \ No newline at end of file diff --git a/docs/images/5-Level2.svg b/docs/images/5-Level2.svg index b13fc127..a0025b91 100644 --- a/docs/images/5-Level2.svg +++ b/docs/images/5-Level2.svg @@ -1,4 +1,4 @@ -
WIQ














HOME










User
WELCOME PAGE
USER MANAGEMENT










AUTHSERVICE
USERSERVICE
GAMEMODE PAGE
QUESTION GAME










GAME CONFIGURATION
QUESTION RESTAPI
QUESTION GENERATOR
Wikidata
GAME
 \ No newline at end of file +
Actor
Wikidata
Gateway service
WIQ
WEBAPP
WIQ SERVICES
Home
Log in
Register
Game Menu
User's game records
Question Game
Questions service
Record service
User service
Authentication service
Users database
Questions database
Question generator
 \ No newline at end of file diff --git a/docs/images/Deployed-Infrastructure.png b/docs/images/Deployed-Infrastructure.png new file mode 100644 index 00000000..12fec7fe Binary files /dev/null and b/docs/images/Deployed-Infrastructure.png differ diff --git a/docs/src/01_introduction_and_goals.adoc b/docs/src/01_introduction_and_goals.adoc index 4f06af2e..91f7b000 100644 --- a/docs/src/01_introduction_and_goals.adoc +++ b/docs/src/01_introduction_and_goals.adoc @@ -55,10 +55,10 @@ See https://docs.arc42.org/section-1/[Introduction and Goals] in the arc42 docum [options="header",cols="1,2"] |=== |Quality attribute|Scenario -| Usability | The user must be able to understand the function of the application before the minute mark. +| Usability | The user must be able to start playing a game before the minute mark. | Performance | The application will be able to operate within reasonable response times, taking into account the already present waiting times (time to answer, between questions, etc). | Security & Privacy | The information stored about a user can only be accessed by said user, never others. -| Robustness | The application will be able to handle any user error that could happen at runtime. +| Robustness | The application will be able to handle any user or external systems (Wikidata) errors. | Accessibility | The application will be accessible by all users, even if the suffer from visual impediments such as colorblindness. |=== diff --git a/docs/src/02_architecture_constraints.adoc b/docs/src/02_architecture_constraints.adoc index 562c0962..36bdd640 100644 --- a/docs/src/02_architecture_constraints.adoc +++ b/docs/src/02_architecture_constraints.adoc @@ -5,7 +5,7 @@ ifndef::imagesdir[:imagesdir: ../images] === Technical constraints Wikidata:: The information needed must be got from this central storage. GitHub:: All the communication and code-sharing will be done by GitHub, so all the work will be recorded there. -API:: Give access about users and generated questions through an API. +Open API:: Give access about users and generated questions through an open API. === Organizational constraints Team size:: The team is formed by 6 people. diff --git a/docs/src/03_system_scope_and_context.adoc b/docs/src/03_system_scope_and_context.adoc index e9304afe..f49d3071 100644 --- a/docs/src/03_system_scope_and_context.adoc +++ b/docs/src/03_system_scope_and_context.adoc @@ -59,11 +59,11 @@ image::3-BusinessContext.drawio.svg["Business context diagram"] |Users request a question to be shown |The question and the set of answers corresponding to that question are presented |*_Question Generation_* -|User requests a question and the information extracted from wikidata +|System requests a question and the information extracted from wikidata |The question and the set of answers corresponding to that question are created |*_Wikidata API_* -|Some part or topic related to the creation of a question -|Some concepts that will facilitate the creation of the question such as wrong answers +|Topic to create a question +|Correct anwser for the topic asked |=== === Technical Context @@ -84,15 +84,24 @@ together with a mapping table showing the relationships between channels and inp **** image::3-TechnicalContext.drawio.svg["Business context diagram"] .User And Application interface + -The user will access the web application via the HTTPs protocol +The user will access the web application via the HTTP protocol .Home and Login interface + -The home will allow user to be redirected to the login and authentication phase via the HTTPs protocol +The home will allow user to be redirected to the login and authentication phase via the HTTP protocol -.Login and Question Generation interface + -The login will allow the user to enter the game and so the question generation will start, this will happend through a redirect +.Login and Users Database + +The login will access the users database directly via an internal network -.Login and Database + -The login will access the database directly via TCP/IP protocol +.Login and Game interface + +The login will allow the user to enter the game menu + +.Game and Users Database + +The game will access the users database directly via an internal network + +.Game and Questions Database + +The game will access the questions database directly via an internal network + +.Question Generator and Questions Database + +The question generator will access the question database directly via an internal network diff --git a/docs/src/04_solution_strategy.adoc b/docs/src/04_solution_strategy.adoc index 8c85e08b..c6bdb431 100644 --- a/docs/src/04_solution_strategy.adoc +++ b/docs/src/04_solution_strategy.adoc @@ -34,14 +34,25 @@ See https://docs.arc42.org/section-4/[Solution Strategy] in the arc42 documentat The technologies chosen for developing the WIQ web app are :: * **ReactJS** : A JavaScript library that facilitates the creation of interactive grafical interfaces. -* **Sass** : A scripting language that is compiled into CSS. It extends CSS by providing several mechanisms such as variables, nested rules, mixins, functions, and inheritance. -* **TypeScript** : A superset of JavaScript that adds various features that can resolve code errors before running the actual code. -* **SpringBoot** : An extension of the Spring framework for creating Java applications. SpringBoot offers many preconfigurations that accelerate the code production process. +* **Sass** : A scripting language that is compiled into CSS. It extends CSS by providing several mechanisms such as variables, nested rules, mixins, functions, and inheritance. (Not used) +* **TypeScript** : A superset of JavaScript that adds various features that can resolve code errors before running the actual code. (Not used) +* **SpringBoot** : An extension of the Spring framework for creating Java applications. SpringBoot offers many preconfigurations that accelerate the code production process. (Not used) * **Wikidata Toolkit** : Wikidata Toolkit is a Java library for accessing Wikidata and other Wikibase installations. It can be used to create bots, to perform data extraction tasks (e.g., convert all data in Wikidata to a new format), and to do large-scale analyses that are too complex for using a simple SPARQL query service. * **Docker** : Docker provides tools and a runtime environment to manage these containers efficiently, allowing developers to build, ship, and run applications consistently across different environments. -* **MySql** : MySQL is an open-source relational database management system that uses SQL for managing and manipulating data. +* **MySql** : MySQL is an open-source relational database management system that uses SQL for managing and manipulating data. (Not used) * **Mongo DB** : MongoDB is a popular open-source NoSQL database management system that stores data flexible, JSON-like documents with dynamic schemas. +* **Express** : Express is a minimal and flexible Node.js web application framework that provides a robust set of features for building web and mobile applications. + +* **Nodejs** : Node.js is an open-source, cross-platform JavaScript runtime environment that executes JavaScript code outside of a web browser, allowing developers to build scalable network applications. + +* **Java** : Java is a high-level, object-oriented programming language developed by Sun Microsystems. It is known for its portability, security features, and wide range of applications, from mobile to enterprise systems. + +* **TO BE ORGANIZED** + + + + === Top-level Decomposition @@ -49,11 +60,16 @@ To be updated along the development of the application where we will add the mos ==== Architectural Patterns -* **Microservices** : Selected as our main architecture. We will have various small independent services that interact between them to support all the fuctionalities of the web application +* **Microservices** : Selected as our main architecture. We will have various small independent services that interact between them to support all the fuctionalities of the web application. + +* **API Gateway** : This API gateway serves as a centralized point for managing, securing, and routing requests between clients and multiple backend services or APIs. This is applied to centralized the calls to the different microservices. + +* **Shared data** : An architectural pattern used to communicate two services through a data repository. In our case, we will communicate the questions generator and the game through a database for a better efficiency and robustness. ==== Design Patterns -* **Façade** : Pattern used to communicate between different parts of the whole application (APIs) +* **Façade** : Pattern used to communicate between different parts of the whole application (APIs). +* **Template** : Pattern used to set some fixed steps of an algorithm. This was used for the different questions generators. === Decisions for achieving quality goals diff --git a/docs/src/05_building_block_view.adoc b/docs/src/05_building_block_view.adoc index df003efb..0f73dbb4 100644 --- a/docs/src/05_building_block_view.adoc +++ b/docs/src/05_building_block_view.adoc @@ -61,9 +61,9 @@ In this level of descomposition we separate the main services of our system show Contained Building Blocks:: -* *_WIQ_ HOME* : Service which will collect the user interaction and redirect it to the corresponding service. -* *_WIQ_ USER MANAGEMENT* : Service that will manage the user information, login, authentication, etc. -* *_WIQ_ QUESTION GAME* Service that will generate and show the different questions for our game. +* *_Webapp_* : The web part of our application that will use the wiq services to let the user play. +* *Gateway service* : Service that will redirect every call to our endpoints to the specific one. +* *_WIQ Services_* : Our collection of endpoints that will attend any need of our Webapp as well as giving support to external calls. === Level 2 @@ -71,16 +71,18 @@ image::5-Level2.svg["Level 2"] Motivation:: -In this level of descomposition of the system we start to identify the different microservices of the system. +In this level of descomposition of the system we identify the different views of the webapp and microservices of the WIQ services. Contained Building Blocks:: -* *_HOME_ WELCOME PAGE* : Microservice that will welcome the user giving a small explanation about the game and facilate the registration/login process. -* *_USER MANAGEMENT_ USERSERVICE* : Microservice that will allow the user create an account for the user and let him access the game. -* *_USER MANAGEMENT_ AUTHSERVICE* : Microservice that will login the user in the system and let him access the game. -* *_HOME_ GAMEMODE PAGE* : Microservice that will let the user start a game. -* *_QUESTION GAME_ GAME CONFIGURATION* Microservice that will let the user customize some game parameters (amount of questions, time to respond a question, etc). -* *_QUESTION GAME_ QUESTION RESTAPI* Microservice that will work as our open API allowing other systems to retrieve information like: - ** Random questions and corresponding answers. -* *_QUESTION GAME_ QUESTION GENERATOR* Microservice that will generate the different questions for our game communicating with wikidata. -* *_QUESTION GAME_ GAME* Microservice that will show the different questions for our game and manage the user answers in order to give a final score. +* *_Webapp_ Home* : First view of the webapp. +* *_Webapp_ Log in and Register* : Views of the webapp that allow the user to get into the application. +* *_Webapp_ Game menu* : Intermediate view between the records and the actual game. +* *_Webapp_ User's games records* : View where the user will be able to see different statistics of the games played (Correct answers, points, total games). +* *_Webapp_ Question Game* : Game view where the user will be able answer the random question by choosing 1 of 4 possibilities. + +* *_WIQ Services_ Authentication service* : Microservice that will let the user log in a created account. +* *_WIQ Services_ User service* : Microservice that will let the user create an account. +* *_WIQ Services_ Record service* : Microservice that will manage the records of all users and will let anyone get the records of a user. +* *_WIQ Services_ Question service* Microservice that will get some random questions for an user game. It will also let anyone get random questions from outside our system. +* *_WIQ Services_ Question generator* Microservice that will generate the random questions accesing wikidata and load them into the system. diff --git a/docs/src/06_runtime_view.adoc b/docs/src/06_runtime_view.adoc index d9f01a78..ed80bd4b 100644 --- a/docs/src/06_runtime_view.adoc +++ b/docs/src/06_runtime_view.adoc @@ -36,142 +36,149 @@ There are many notations for describing scenarios, e.g. See https://docs.arc42.org/section-6/[Runtime View] in the arc42 documentation. **** - -=== Runtime Scenario: Retrieval of questions - -[plantuml,"Retrieval of questions",png] ----- -actor User -entity Frontend as "Webapp Frontend" -entity Backend as "Webapp Backend" -database Wikidata -User -> Frontend: next question -Frontend -> Backend: get question -Backend -> Wikidata: request data\n(1s timeout) -Wikidata -> Backend: receive data -Backend -> Backend: generate question -Backend -> Frontend: return question and answers -Frontend -> User: show question ----- - -=== Runtime Scenario: Answer questions - -[plantuml,"Answer questions",png] ----- -actor User -entity Frontend as "Webapp Frontend" -entity Backend as "Webapp Backend" -database DB -User -> Frontend: answer\n(30s timelimit) -Frontend -> Frontend: process answer -Frontend -> Backend: forward result -Backend -> DB: store result\n(1s timeout) -Backend -> Frontend: answer -Frontend -> User: show correctness ----- - -=== Runtime Scenario: Login successful - -[plantuml,"Login successful",png] ----- -actor User -entity Frontend as "Webapp Frontend" -entity Backend as "Webapp Backend" -database DB -User -> Frontend: send credentials -Frontend -> Backend: forward credentials -Backend -> DB: query for username\n(1s timeout) -DB -> Backend: retrieve user data -Backend -> Backend: validate password -Backend -> Frontend: login successful -Frontend -> User: login successful ----- - -=== Runtime Scenario: Login failure - -[plantuml,"Login failure",png] ----- -actor User -entity Frontend as "Webapp Frontend" -entity Backend as "Webapp Backend" -database DB -User -> Frontend: send credentials -Frontend -> Backend: forward credentials -Backend -> DB: query for username\n(1s timeout) -DB -> Backend: retrieve user data -Backend-> Backend: validate password -Backend -> Frontend: wrong password -Frontend -> User: ask for credentials -User -> Frontend: send credentials -Frontend -> Backend: ... ----- - -=== Runtime Scenario: Signup successful - -[plantuml,"Signup successful",png] ----- -actor User -entity Frontend as "Webapp Frontend" -entity Backend as "Webapp Backend" -database DB -User -> Frontend: send signup form -Frontend -> Backend: forward signup form -Backend -> DB: check if username exists\n(1s timeout) -DB -> Backend: answer -Backend -> DB: insert data\n(1s timeout) -Backend -> Frontend: signup successful -Frontend -> User: signup successful ----- - -=== Runtime Scenario: Signup failure - -[plantuml,"Signup failure",png] ----- -actor User -entity Frontend as "Webapp Frontend" -entity Backend as "Webapp Backend" -database DB -User -> Frontend: send signup form -Frontend -> Backend: forward signup form -Backend -> DB: check if username exists\n(1s timeout) -DB -> Backend: answer -Backend -> Frontend: error: username in use -Frontend -> User: username in use -User -> Frontend: send new username -Frontend -> Backend: forward new username -Backend -> DB: ... ----- - -=== Runtime Scenario: Wikidata error - -[plantuml,"Wikidata error",png] ----- -actor User -entity Frontend as "Webapp Frontend" -entity Backend as "Webapp Backend" -database Wikidata -User -> Frontend: next question -Frontend -> Backend: get question -Backend -> Wikidata: request data -Wikidata -> Backend: error/timeout -Backend -> Backend: error handling -Backend -> Frontend: wikidata error -Frontend -> User: show error message ----- - -=== Runtime Scenario: DB error - -[plantuml,"DB error",png] +In this section we will focus on developing which views of the webapp use which microservices from the WIQ Services. +Mind that some of these processes work the same way when called from outside the system (look for them at the API docs) + +=== Runtime Scenario: Signup + +[plantuml,"Signup",png] +---- +entity Webapp as "Sign in view" +entity Gateway_service as "Gateway service" +entity Microservice as "Authentication service" +database Users_database +Webapp -> Gateway_service: Sends signup form +Gateway_service -> Microservice: Forward the petition\nto the specific microservice +Microservice -> Microservice : Checks the petition +alt data is valid + Microservice -> Users_database : Check if username or email exists + Users_database --> Microservice: Answers + alt email is not registered nor username + Microservice -> Microservice: Creates a respond with user's data + Microservice --> Gateway_service: Forwards the respond + Gateway_service --> Webapp : Responds to the petition + Webapp -> Webapp : Logs into the application + else email or username exists + Microservice --> Gateway_service: Responds with an error + Gateway_service --> Webapp : Forwards the petition + Webapp -> Webapp : Show the error + end +else data is invalid + Microservice --> Gateway_service: Responds with some error(s) + Gateway_service --> Webapp: Forwards the respond + Webapp -> Webapp: Shows the error(s) +end +---- +=== Runtime Scenario: Login + +[plantuml,"Login",png] +---- +entity Webapp as "Log in view" +entity Gateway_service as "Gateway service" +entity Microservice as "User service" +database Users_database +Webapp -> Gateway_service: Sends log in form +Gateway_service -> Microservice: Forward the petition\nto the specific microservice +Microservice -> Microservice : Checks the petition +alt data is valid + Microservice -> Users_database : Check if username exists + Users_database --> Microservice: Answers + alt users exists + Microservice -> Microservice: Creates a respond with user's data + Microservice --> Gateway_service: Forwards the respond + Gateway_service --> Webapp : Responds to the petition + Webapp -> Webapp : Logs into the application + else users does not exist + Microservice --> Gateway_service: Responds with an error + Gateway_service --> Webapp : Forwards the petition + Webapp -> Webapp : Show the error + end +else data is invalid + Microservice --> Gateway_service: Responds with some error(s) + Gateway_service --> Webapp: Forwards the respond + Webapp -> Webapp: Shows the error(s) +end +---- + +=== Runtime Scenario: Generation of questions + +[plantuml,"Generation of questions",png] +---- +entity Microservice as "Question generator" +entity Wikidata as "Wikidata" +database Questions_database + +group Repeats after some time + Microservice -> Wikidata : Asks for information\nto generate questions + alt Wikidata is working + Wikidata --> Microservice : Returns the information + Microservice -> Microservice : Generates the question,\ncorrect answer and distractors + group Transaction + Microservice -> Questions_database : Removes questions that exist + Questions_database --> Microservice : Confirms remove operation + Microservice -> Questions_database : Saves the new questions + Questions_database --> Microservice : Confirms add operation + end group + end alt + Microservice -> Microservice : Goes to sleep +end group +---- + +=== Runtime Scenario: Play a game + +[plantuml,"Play a game",png] ---- actor User -entity Frontend as "Webapp Frontend" -entity Backend as "Webapp Backend" -database DB -User -> Frontend: request -Frontend -> Backend: request -Backend -> DB: request -DB -> Backend: error/timeout -Backend -> Backend: error handling -Backend -> Frontend: DB error -Frontend -> User: show error message +entity Webapp as "Question game" +entity Gateway_service as "Gateway service" +entity Microservice1 as "Question service" +entity Microservice2 as "Record service" +database DB as "Questions database" +database UDB as "Users database" + +Webapp -> Gateway_service: Sends a petition for questions\nwith some parameters +Gateway_service -> Microservice1: Forwards the petition +Microservice1 -> DB : Select some questions\nfor those parameters +alt Database is working + DB --> Microservice1 : Retrieve some questions + Microservice1 -> Microservice1 : Formats the questions retrieved\ninto JSON format + Microservice1 --> Gateway_service: Responds with the JSON + Gateway_service --> Webapp : Forwards the respond + Webapp -> Webapp : Process the JSON and\nstarts the game + loop Till there are no more questions + alt Time has not run out + User -> Webapp : Clicks an answer + Webapp -> Webapp : Checks the answer + end alt + Webapp -> User : Show correct answer + end loop + Webapp -> User : Shows use the game statistics + Webapp -> Gateway_service : Sends the statistics of the game\nFire and forget + Gateway_service -> Microservice2 : Forwards the message + Microservice2 -> UDB : Saves the record + alt Users database is not working + Microservice2 -> Microservice2 : Saves the record\nwill try with next request\nto save both records + end alt +else Database is not working + Microservice1 --> Gateway_service : Responds with an error + Gateway_service --> Webapp : Forwards the respond + Webapp -> Webapp : Process the error + Webapp --> User : Advise in a friendly way\n(Oven cannot bake\nquestions right now) +end +---- + +=== Runtime Scenario: Accessing a record +[plantuml,"Accessing a record",png] +---- +entity Webapp as "Record view" +entity Gateway_service as "Gateway service" +entity Microservice as "Record service" +database DB as "Users_database" +Webapp -> Gateway_service: Asks for the record\nof the logged user +Gateway_service -> Microservice: Forward the petition\nto the specific microservice +Microservice -> DB : Finds the user's record +DB --> Microservice : Returns the user's record +Microservice --> Gateway_service : Sends the respond +Gateway_service --> Webapp : Forwards the respond +Webapp -> Webapp : Parses the record\nand shows it ---- diff --git a/docs/src/07_deployment_view.adoc b/docs/src/07_deployment_view.adoc index eaba8299..a161d91c 100644 --- a/docs/src/07_deployment_view.adoc +++ b/docs/src/07_deployment_view.adoc @@ -56,6 +56,61 @@ Describe (usually in a combination of diagrams, tables, and text): For multiple environments or alternative deployments please copy and adapt this section of arc42 for all relevant environments. **** +image::Deployed-Infrastructure.png["Deployed Infrastructure"] + +**** +component User as "User" +cloud "WIQ" { + rectangle "Azure - Ubuntu - Docker"{ + component webapp as "Webapp"{ + port 3000 + } + rectangle "Internal network"{ + database "MongoDB" { + folder "UsersDB" { + [Records] + [Users] + } + frame "QuestionsDB" { + [Questions] + } + } + component gs as "Gateway service"{ + port 8000 + } + component auths as "Authentication service"{ + port 8002 + } + component users as "User service"{ + port 8001 + } + component records as "Record service"{ + port 8004 + } + component questions as "Question service"{ + port 8003 + } + component qg as "Question generator" + } + } +} +cloud "Wikidata" + +User -[dotted,#green,thickness=3]-> 3000 +webapp -[#green,thickness=3]-> 8000 +gs -[#red]-> 8002 +gs -[#red]-> 8001 +gs -[#red]-> 8004 +gs -[#red]-> 8003 +auths -[#red]-> Users +users -[#red]-> Users +records -[#red]-> Records +questions -[#red]-> Questions +qg -[#red]-> Questions +qg -[dotted]-> Wikidata +**** +This diagram shows the infrastructure of our application when deployed. + *TBD* === Infrastructure Level 2 @@ -67,4 +122,3 @@ Here you can include the internal structure of (some) infrastructure elements fr Please copy the structure from level 1 for each selected element. **** -*TBD* \ No newline at end of file diff --git a/docs/src/09_architecture_decisions.adoc b/docs/src/09_architecture_decisions.adoc index d4c0636f..e87d7169 100644 --- a/docs/src/09_architecture_decisions.adoc +++ b/docs/src/09_architecture_decisions.adoc @@ -3,8 +3,23 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-design-decisions]] == Architecture Decisions The application will be carried out following a Microservices architecture. + -The Rest API in charge of comunicating with WikiData will be coded using Java. + -_(More details to de added)_ + +The service in charge of comunicating with WikiData will be coded using Java. +As the generation of questions is a huge part of our application we will play it safe by using Java, a language where most of the team is "fluent" at. + + +The backend will we develop using a combination of SpringBoot, for the question generation, and Express. +The use of SpringBoot was a requirement in order to generate the questions in Java. + + +*10/03/24* + +We will apply a data share strategy where we will load the questions generated and access them when needed through the backend. +This is done to increase the efficiency, as questions are not generated when needed, and robustness of the application, as we can give service even if Wikidata is down. + + +*14/03/24* + +We have done a redisign of the architecture of the project where we will implement the whole backend using Express. +This was done to have a more homogeneus backend as we have de-coupled the question generation from the backend and we dont need all to be Java. + + [role="arc42help"] **** diff --git a/docs/src/11_technical_risks.adoc b/docs/src/11_technical_risks.adoc index 022fa93a..a0100905 100644 --- a/docs/src/11_technical_risks.adoc +++ b/docs/src/11_technical_risks.adoc @@ -27,12 +27,12 @@ In decision-making processes, we often face constraints. These constraints, know ### Risks -There is the table of risks the team is taking for development purposes ordered by priority. +There is the table of risks the team is taking for development purposes. [options="header",cols="^.^1,2,2"] |=== |Risk|Explanation|Solution -| *Insufficient knowledge of React* | None of our team members worked with React before. | The people who's going to work on React are going to learn it. +| *Insufficient knowledge of Tecnologies* | None of our team members worked with React nor Express nor MongoDB before. | The people who's going to work on these technologies are going to learn it which trades time for a better application as we use stronger technologies (React instead of HTML). | *Working with a team* | It might be difficult working with people on projects, as every person has their own way of doing things. | Have weekly meetings deciding on what's going to get solved, how and by whom, keeping bus factor in mind. | *Time* | It should be kept in mind that the team has deadlines with different requirements, demanding them to work regularly. | Have better time-management skills, keep track of and help each other to not waste any time on hard / complex parts of the project. |=== @@ -44,5 +44,5 @@ There is the table of technical debt shortcuts the team is taking sacrificing lo [options="header",cols="^.^1,3"] |=== |Technical debt|Explanation -| *Azure* | The team has experience with Microsoft Azure and decided to use it again. The full implementation is not planned yet. +| *CORS* | The team has fully enabled CORS through the backend this is a risk as external users can access endpoints like adduser |=== \ No newline at end of file diff --git a/docs/src/12_glossary.adoc b/docs/src/12_glossary.adoc index b5ba9d7a..ec89a6b1 100644 --- a/docs/src/12_glossary.adoc +++ b/docs/src/12_glossary.adoc @@ -48,4 +48,7 @@ See https://docs.arc42.org/section-12/[Glossary] in the arc42 documentation. |*Stakeholder* |Anyone involved in the development process of the system, or that is affected by it somehow. + +|*CORS* +|CORS (Cross-Origin Resource Sharing) is a mechanism that allows resources on a web page to be requested from another domain outside the domain from which the resource originated. |===