Doc 4 point updated

docs/src/04_solution_strategy.adoc

@@ -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.
 
 |===
@@ -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.