Skip to content

Commit

Permalink
Merge pull request #219 from Arquisoft/develop
Browse files Browse the repository at this point in the history
Fix coverage and update documentation
  • Loading branch information
uo289321 authored Apr 30, 2024
2 parents 06b5328 + 630b8d2 commit 7ca6eb2
Show file tree
Hide file tree
Showing 13 changed files with 110 additions and 43 deletions.
2 changes: 1 addition & 1 deletion cyt-utils/package.json
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"name": "cyt-utils",
"version": "4.0.0",
"version": "4.1.0",
"description": "A variety of utilities for the project",
"main": "index.js",
"scripts": {
Expand Down
15 changes: 9 additions & 6 deletions docs/src/01_introduction_and_goals.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -28,35 +28,38 @@ The application must have the following functionalities:

* A front-end web that allows users to register and play the game.
* A user registration system with a history of their games.
* All of the questions data must be obtained from the WikiData knowledge database.
* All the questions data must be obtained from the WikiData knowledge database.
* The application must have an API to obtain users information.
* The application must have an API to obtain generated questions.

Further information can be found link:https://docs.google.com/document/d/1pahOfYFY--Wi7_9bbxiKOGevB_9tOSyRm78blncgBKg/[here].
Further information can be found link:https://unioviedo-my.sharepoint.com/:b:/g/personal/uo276255_uniovi_es/ES2-y4wEcjBIgM8nCghtDJMBv3tlu08WjjhTeQdwdLKTZA?e=Saxsim/[here].

=== Quality Goals

The following table describes the project's quality goals in a descending order.
The following table describes the project's quality goals in descending order.

|===
| Quality Goal | Motivation

| *_Efficiency_*
| As it's a game, one of its main objectives is efficiency, as the game needs to run swiftly and smoothly.

| *_Usability_*
| The application must be not only easy to learn and use but also fun because if a game has no joy in it, then it shall never be called for that name.

| *_Maintainability_*
| Projects must always have enough quality to be able to be modified without making more changes than necessary.
Not following this principle would heavily increase costs in new feature implementation or bug solving that may arise in the future.

| *_Security_*
| Security is always key and therefore effort will be put into fighting against unauthorised access of information, including the users' personal or sensitive data that the information system may contain.

| *_Scalability_*
| Given an exponential growth of users, the application should allow for capacity resizing and overall a robust handling for a large number of connections.

| *_Testability_*
| The performance of the system is needed to be tested covering as many use cases as possible so all the other goals will be met.

| *_Security_*
| Security is always key and therefore effort will be put into fighting against unauthorised access of information, including the users' personal or sensitive data that the information system may contain.

|===

=== Stakeholders
Expand Down
8 changes: 4 additions & 4 deletions docs/src/03_system_scope_and_context.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -37,8 +37,8 @@ image::03_business_context.drawio.png["Diagram of business context", align="cent
| Response to the answers of the user

| *_Users_*
| Answers to questions from the app, provides autentification data
| Interaction with the app interface to login and play
| Answers to questions from the app, provides authentication data
| Interaction with the app interface to log in and play

| *_Wikidata_*
| Request an specific category's questions and their possible answers
Expand Down Expand Up @@ -68,8 +68,8 @@ image::03_technical_context.drawio.png["Technical Context diagram", align="cente
| User's history

| *_Users_*
| Questions and posible answers
| Interaction to login and answer to questions
| Questions and possible answers
| Interaction to log in and answer to questions

| *_Wikidata_*
| Request for question data with category
Expand Down
35 changes: 17 additions & 18 deletions docs/src/04_solution_strategy.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -10,54 +10,53 @@ we have decided to use the following technologies, as they were the one given to

* *_JavaScript_*: Main programming language. It is used in both back and front end.
* *_React_*: JavaScript library used in the design of graphical user interfaces.
* *_ExpressJS_*: Framework built on the top of _Node.js_ and used in the backend.
* *_Express.js_*: Framework built on the top of _Node.js_ and used in the backend.
* *_MongoDB_*: Several instances are used to persist the information of the app.
* *_Github_*: Used for versioning the proyect and as a mean of communication for the dev team.
* *_GitHub_*: Used for versioning the project and as a mean of communication for the dev team.
* *_Docker_*: Used for the app deployment.
* *_Github actions_*: Used for testing purposes, app deployment and as a CI/CD tool.
* *_GitHub actions_*: Used for testing purposes, app deployment and as a CI/CD tool.

=== Top-level Decomposition

We have decided to implement a microservices arquitecture, with diferrent modules
for different purpouses. For instance, we currently have the following microservices:
We have decided to implement a microservices architecture, with different modules
for different purposes. For instance, we currently have the following microservices:

* *_User service_*: Service used to add new users.
* *_User service_*: Service used to add new users, and also manage friends system.
* *_Auth service_*: Service used for the authentication of users.
* *_Gateway service_*: Service exposed to the public and used as a proxy to the two previous ones.
* *_Webapp service_*. Web application that uses the _gateway service_ to allow basic login and user features.
* *_Jordi service_*. Sevice to generate and return questions from the Wikidata API.
* *_Userhistory service_*. Service to generate the user's history and global ranking.
// TODO: Fill with the upcoming microservices
* *_Jordi service_*. Service to generate and return questions from the Wikidata API.
* *_User history service_*. Service to generate the user's history and global ranking.

=== Decisions taken to achieve quality goals

|===
| Quality goal | Decision made

|*_Usability_*
|The user must be able to use the application without any doubt or trouble. For this purpouse,
we must use internationalice the app, so it can be used by people from different countries,
|The user must be able to use the application without any doubt or trouble. For this purpose,
we must use internationalize the app, so it can be used by people from different countries,
elect a good font and its size, and make the app responsive.

|*_Perfomance_*
|*_Performance_*
|To optimize performance and reduce the risk of system overload, we are strategically reducing our requests to WikiData.
This measure will help maintain stable service. Additionally, we are enhancing our infrastructure by upgrading from an
Azure B1s VM to a more capable Oracle Cloud VM.Standard.A1.Flex instance, which features 4 OCPU cores, 24 GB of RAM, and 50 GB of storage.
Azure B1s VM to a more capable Oracle Cloud VM.Standard.A1.Flex instance, which features 4 CPU cores, 24 GB of RAM, and 50 GB of storage.

To further alleviate server stress, we have recalibrated our monitoring probes to gather data at 15-second intervals.
We are also implementing a reverse proxy in our application to serve as a load balancer.
This setup efficiently distributes traffic across various microservices and caches static content,
significantly reducing backend server load and improving user response times.

|*_Maintainability and Escalability_*
|The application must be well structured so that modifications or expansions can be made in a straightforward manner
|*_Maintainability and Scalability_*
|The application must be well-structured so that modifications or expansions can be made in a straightforward manner
without requiring excessive alterations to existing code. To achieve this, along with employing a microservices architecture,
we will utilize design patterns and coding conventions to maintain clean, maintainable code.

To be more specific, the Gateway Pattern and the Single Responsibility Pattern define the architectural design
principles that we will follow in our microservices implementation. The Gateway Pattern will be used to provide a unified
entry point for all external requests, while the Single Responsibility Pattern will ensure that each microservice has a clear and specific role.
Also we will integrate a reverse proxy to our application to serve as a load balancer, which will help us to scale our application horizontally.
Also, we will integrate a reverse proxy to our application to serve as a load balancer, which will help us to scale our application horizontally.
Also simplifies the SSL configuration and the management of the certificates.

|===
Expand All @@ -68,8 +67,8 @@ Also simplifies the SSL configuration and the management of the certificates.
We have taken the following organizational decisions:

* *_Tasks_*: We have decided to distribute the tasks equally per person so that everyone has approximately the same workload. We think it is a good idea that once a task is done, it should be reviewed by at least 50% of the group to be taken as valid.
* *_Github Issues_*: We make use of _Github Issues_ to create the tasks mentioned above and assign them to different team members. We will also use them to discuss any critical decisions that need to be made about the project.
* *_Github Projects_*: We also take into account _Github Projects_ to organize the workflow and to track the progress of the project.
* *_GitHub Issues_*: We make use of _GitHub Issues_ to create the tasks mentioned above and assign them to different team members. We will also use them to discuss any critical decisions that need to be made about the project.
* *_GitHub Projects_*: We also take into account _GitHub Projects_ to organize the workflow and to track the progress of the project.
* *_Language_*: We have agreed that we will develop the project in _English_ so the code and documentation will use it as the main language. This way we will guarantee that the project is accessible to everyone.
* *_External Meetings_*: We have decided to have meetings on a regular basis to discuss the progress of the project and to make decisions about the next steps to be taken.
* *_Internal Communication_*: We have decided to use Discord as the main communication channel for the project. We will use it to discuss any issues that arise during the development of the project. The support of Github Webhooks will be used to notify the team of any changes in the repository.
Expand Down
2 changes: 1 addition & 1 deletion docs/src/05_building_block_view.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -66,7 +66,7 @@ Contained Building Blocks::
|Service containing all user related information such as scores or history of games played.

|Questions
|Service that bears the responsability of interacting with te Wikidata API and generating the questions to be presented to the user.
|Service that bears the responsibility of interacting with te Wikidata API and generating the questions to be presented to the user.

|===

Expand Down
4 changes: 2 additions & 2 deletions docs/src/07_deployment_view.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ ifndef::imagesdir[:imagesdir: ../images]

The infrastructure of our system consists mainly on a single server, which is hosted in
an Oracle Virtual Machine arm64 running Ubuntu 22.04 LTS. It contains a dockerized
NodeJS app based on microservices architecture which exposes port 443 and 80 to
Node.js app based on microservices architecture which exposes port 443 and 80 to
the internet as an entry point to the user interface of the system aswell as for the API.
The server contains a MongoDB database used to store the application data.
The system also interacts with the Wikidata API in order to provide
Expand All @@ -30,7 +30,7 @@ Quality and/or Performance Features::

- Maintainability: The system can be updated (each container can be maintained/updated individually) by replacing the docker containers with new versions of the application, which allows the system to be maintained without remarkable issues.

- Security: The system is hosted in a secure environment (each container is a isolated enviroment, so in the case of a security breach, it only affects one of them) provided by the Azure cloud platform, which ensures its security and availability.
- Security: The system is hosted in a secure environment (each container is a isolated environment, so in the case of a security breach, it only affects one of them) provided by the Azure cloud platform, which ensures its security and availability.

Mapping of Building Blocks to Infrastructure::

Expand Down
8 changes: 4 additions & 4 deletions docs/src/10_quality_requirements.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -5,9 +5,9 @@ ifndef::imagesdir[:imagesdir: ../images]

The required quality goals are:

- Perfomance: Performance is critical in the application, especially in the game itself.
- Performance: Performance is critical in the application, especially in the game itself.
This is intended to save the user long waiting times between questions, providing a fast and fluid experience.
- Maintainability and Escalability: The application must be well structured so that functionalities
- Maintainability and Scalability: The application must be well-structured so that functionalities
can be added or modified at any time in a simple and intuitive way, which will facilitate the work of the developers.
- Scalability: The application should be able to handle a large number of concurrent users and scale horizontally as the user base grows.
- Availability: The application should be highly available, with minimal downtime and the ability to recover quickly from failures.
Expand Down Expand Up @@ -56,7 +56,7 @@ to the main page of the game, if not, it returns them to the login screen and
informs them of the error.
|===

===== Perfomance
===== Performance

|===
| Usage Scenario | System Response
Expand All @@ -80,7 +80,7 @@ quickly know what they have to do to register and how they have to use the appli
|===
==== Change scenarios

===== Maintainability and Escalability
===== Maintainability and Scalability

|===
| Change Scenario | System Response
Expand Down
2 changes: 1 addition & 1 deletion docs/src/11_technical_risks.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -76,7 +76,7 @@ This is mainly because load balancing and auto-scaling are not implemented yet.

| Inadequate security measures
| 4
| The project's security measures may not be sufficient to protect against common threats such as, cross-site scripting, and DDoS attacks. Regular security audits and penetration testing are essential to identify vulnerabilities and ensure that the project's security measures are up to date.
| The project's security measures may not be sufficient to protect against common threats such as, cross-site scripting, and DDoS attacks. Regular security audits and penetration testing are essential to identify vulnerabilities and ensure that the project's security measures are up-to-date.

| Make the entire web internationalized
| 6
Expand Down
2 changes: 1 addition & 1 deletion docs/src/12_testing_report.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ Our end-to-end approach focused on this functionality:
- Login / register

=== 12.3. Gatling tests
TODO when deployes
TODO when deploys

=== 12.4. Usability tests

Expand Down
2 changes: 1 addition & 1 deletion docs/src/13_glossary.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -25,7 +25,7 @@ ifndef::imagesdir[:imagesdir: ../images]
| API consumed by the application to generate the questions of the game

| ADR
| Arquitechtural Design Record.
| Architectural Design Record.

| Continuous integration and delivery
|The process of automating the integration of code changes from multiple contributors into a single software project.
Expand Down
44 changes: 44 additions & 0 deletions gatewayservice/routes/authRoutes.test.js
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
const request = require('supertest');
const express = require('express');
const axios = require('axios');
const authRoutes = require('./authRoutes');

jest.mock('axios');

const app = express();
app.use(express.json());
authRoutes(app, axios);

describe('Auth Routes', () => {
it('logs in with valid credentials', async () => {
axios.post.mockResolvedValue({ data: { token: 'token', username: 'username', userId: 'userId' } });

const res = await request(app).post('/login').send({ username: 'username', password: 'password' });
expect(res.statusCode).toEqual(200);
expect(res.body).toHaveProperty('token');
expect(res.body).toHaveProperty('username');
expect(res.body).toHaveProperty('userId');
});

it('fails to log in with invalid credentials', async () => {
axios.post.mockRejectedValue({ response: { status: 401, data: 'Unauthorized' } });

const res = await request(app).post('/login').send({ username: 'username', password: 'password' });
expect(res.statusCode).toEqual(401);
});

it('validates a valid token', async () => {
axios.get.mockResolvedValue({ data: { valid: true } });

const res = await request(app).get('/validate/token');
expect(res.statusCode).toEqual(200);
expect(res.body).toEqual({ valid: true });
});

it('fails to validate an invalid token', async () => {
axios.get.mockRejectedValue({ response: { status: 401, data: 'Unauthorized' } });

const res = await request(app).get('/validate/invalid');
expect(res.statusCode).toEqual(401);
});
});
21 changes: 21 additions & 0 deletions gatewayservice/routes/gatewayRoutes.test.js
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
const request = require('supertest');
const express = require('express');
const gatewayRoutes = require('./gatewayRoutes');

const app = express();
app.use(express.json());
gatewayRoutes(app);

describe('Gateway Routes', () => {
it('returns health status', async () => {
const res = await request(app).get('/health');
expect(res.statusCode).toEqual(200);
expect(res.body).toEqual({ status: "OK" });
});

it('returns a teapot status', async () => {
const res = await request(app).get('/');
expect(res.statusCode).toEqual(418);
expect(res.body).toEqual({ message: "¯\_(ツ)_/¯" });
});
});
8 changes: 4 additions & 4 deletions sonar-project.properties
Original file line number Diff line number Diff line change
Expand Up @@ -9,9 +9,9 @@ sonar.projectVersion=1.0
sonar.host.url=https://sonarcloud.io
sonar.language=js

sonar.coverage.exclusions=**/*.test.js,**/*.draft.js,**/*.py
sonar.cpd.exclusions=**/*.test.js,**/*.draft.js,**/*.py
sonar.sources=users/authservice,users/userservice,gatewayservice,webapp/src,userhistory,jordi
sonar.coverage.exclusions=**/*.test.js,**/*.draft.js
sonar.cpd.exclusions=**/*.test.js,**/*.draft.js
sonar.sources=users/authservice/routes,users/userservice/routes,gatewayservice/routes,webapp/src,userhistory/routes,jordi/routes
sonar.sourceEncoding=UTF-8
sonar.exclusions=node_modules/**
sonar.javascript.lcov.reportPaths=**/coverage/lcov.info
sonar.javascript.lcov.reportPaths=**/coverage/lcov.info

0 comments on commit 7ca6eb2

Please sign in to comment.