Merge pull request #99 from Arquisoft/develop

Release

.github/workflows/build.yml

@@ -10,6 +10,8 @@ jobs:
     runs-on: ubuntu-latest
     steps:
     - uses: actions/checkout@v4
+      with:
+        fetch-depth: 0
     - uses: actions/setup-node@v4
       with:
         node-version: 20

.github/workflows/release.yml

@@ -163,4 +163,4 @@ jobs:
           wget https://raw.githubusercontent.com/arquisoft/wiq_es2b/master/docker-compose.yml -O docker-compose.yml
           wget https://raw.githubusercontent.com/arquisoft/wiq_es2b/master/.env -O .env
           docker compose --profile prod down
-          docker compose --profile prod up -d --pull always
+          docker compose --profile prod up -d --pull always

README.md

@@ -31,6 +31,12 @@ and launch it with docker compose:
 docker compose --profile dev up --build
 ```
 
+and tear it down:
+
+```sh
+docker compose --profile dev down
+```
+
 ### Starting Component by component
 
 First, start the database. Either install and run Mongo or run it using docker:
@@ -100,15 +106,18 @@ deploy:
         user: ${{ secrets.DEPLOY_USER }}
         key: ${{ secrets.DEPLOY_KEY }}
         command: |
-          wget https://raw.githubusercontent.com/arquisoft/wiq_es2b/master/docker-compose.yml -O docker-compose.yml
-          wget https://raw.githubusercontent.com/arquisoft/wiq_es2b/master/.env -O .env
-          docker compose down
-          docker compose --profile prod up -d
+
+          wget https://raw.githubusercontent.com/arquisoft/wiq_0/master/docker-compose.yml -O docker-compose.yml
+          wget https://raw.githubusercontent.com/arquisoft/wiq_0/master/.env -O .env
+          docker compose --profile prod down
+          docker compose --profile prod up -d --pull always
+
 ```
 
 This action uses three secrets that must be configured in the repository:
 - DEPLOY_HOST: IP of the remote machine.
 - DEPLOY_USER: user with permission to execute the commands in the remote machine.
 - DEPLOY_KEY: key to authenticate the user in the remote machine.
 
-Note that this action logs in the remote machine and downloads the docker-compose file from the repository and launches it. Obviously, previous actions have been executed which have uploaded the docker images to the GitHub Packages repository.
+Note that this action logs in the remote machine and downloads the docker-compose file from the repository and launches it. 
+Obviously, previous actions have been executed which have uploaded the docker images to the GitHub Packages repository.

docs/src/06_runtime_view.adoc

@@ -3,63 +3,27 @@ ifndef::imagesdir[:imagesdir: ../images]
 [[section-runtime-view]]
 == Runtime View
 
-
-[role="arc42help"]
-****
-.Contents
-The runtime view describes concrete behavior and interactions of the system’s building blocks in form of scenarios from the following areas:
-
-* important use cases or features: how do building blocks execute them?
-* interactions at critical external interfaces: how do building blocks cooperate with users and neighboring systems?
-* operation and administration: launch, start-up, stop
-* error and exception scenarios
-
-Remark: The main criterion for the choice of possible scenarios (sequences, workflows) is their *architectural relevance*. It is *not* important to describe a large number of scenarios. You should rather document a representative selection.
-
-.Motivation
-You should understand how (instances of) building blocks of your system perform their job and communicate at runtime.
-You will mainly capture scenarios in your documentation to communicate your architecture to stakeholders that are less willing or able to read and understand the static models (building block view, deployment view).
-
-.Form
-There are many notations for describing scenarios, e.g.
-
-* numbered list of steps (in natural language)
-* activity diagrams or flow charts
-* sequence diagrams
-* BPMN or EPCs (event process chains)
-* state machines
-* ...
-
-
-.Further Information
-
-See https://docs.arc42.org/section-6/[Runtime View] in the arc42 documentation.
-
-****
-
-=== <Runtime Scenario 1>
-
-
-* _<insert runtime diagram or textual description of the scenario>_
-* _<insert description of the notable aspects of the interactions between the
-building block instances depicted in this diagram.>_
-
-It is possible to use a sequence diagram:
-
-[plantuml,"Sequence diagram",png]
+=== User plays a game
+When the game is started, the app will call the createquestion service that is in charge of provide generated questions from wikidata information.
+[plantuml,"Start a game",png]
 ----
-actor Alice
-actor Bob
-database Pod as "Bob's Pod"
-Alice -> Bob: Authentication Request
-Bob --> Alice: Authentication Response
-Alice  --> Pod: Store route
-Alice -> Bob: Another authentication Request
-Alice <-- Bob: another authentication Response
+actor a as "User"
+participant q as "Game GUI"
+participant w as "CreateQuestions service"
+database d as "Database"
+
+
+a -> q: Start the game
+loop number of questions
+q -> w: Ask for a question
+w -->q: Returns the question
+q -> d: Store the question
+q -> a: Returns the question
+
+a -> q: Pick an answer
+q -> a: Shows if the answer was valid or not
+a -> q: Asks for next question
+end
+q -> a: Show the game stats
+q -> d: Store the game with questions, answers and stats
 ----
-
-=== <Runtime Scenario 2>
-
-=== ...
-
-=== <Runtime Scenario n>

gatewayservice/gateway-service.js

@@ -2,6 +2,11 @@ const express = require('express');
 const axios = require('axios');
 const cors = require('cors');
 const promBundle = require('express-prom-bundle');
+//libraries required for OpenAPI-Swagger
+const swaggerUi = require('swagger-ui-express'); 
+const fs = require("fs")
+const YAML = require('yaml')
+
 
 const app = express();
 const port = 8000;
@@ -41,31 +46,74 @@ app.post('/adduser', async (req, res) => {
   }
 });
 
-app.post('/createquestion', async (req, res) => {
+
+app.post('/addgame', async (req, res) => {
+  try {
+    const userResponse = await axios.post(userServiceUrl+'/addgame', req.body);
+    res.json(userResponse.data);
+  } catch (error) {
+    res.status(error.response.status).json({ error: error.response.data.error });
+  }
+});
+
+
+app.get('/getgamehistory/:username', async (req, res) => {
+  try {
+    const username = req.params.username;
+    const userResponse = await axios.get(`${userServiceUrl}/getgamehistory/${username}`);
+    res.json(userResponse.data);
+  } catch (error) {
+    res.status(error.response.status).json({ error: error.response.data.error });
+  }
+});
+
+
+
+app.get('/createquestion', async (req, res) => {
   try {
     // Create a petition to the URL (le llegará a creation-service.js) with the option /createquestion and the req.body params
-    const questionResponse = await axios.post(creationServiceUrl+'/createquestion', req.body);
+    const questionResponse = await axios.get(creationServiceUrl+'/createquestion', req.body);
     // Return a json response with what we obtained on the petition
     res.json(questionResponse.data);
   } catch (error) {
     res.status(error.response.status).json({ error: error.response.data.error });
   }
 });
 
-app.post('/getquestionshistory', async (req, res) => {
+app.get('/getquestionshistory', async (req, res) => {
   try {
     // Create a petition to the URL (le llegará a retrieve-service.js) with the option /getgeneratedquestions and the req.body params
-    const questionResponse = await axios.post(retrieveServiceUrl+'/getquestionshistory', req.body);
+    const questionResponse = await axios.get(retrieveServiceUrl+'/getquestionshistory', req.body);
     // Return a json response with what we obtained on the petition
     res.json(questionResponse.data);
   } catch (error) {
     res.status(error.response.status).json({ error: error.response.data.error });
   }
 });
 
+
+
+// Read the OpenAPI YAML file synchronously
+openapiPath='./openapi.yaml'
+if (fs.existsSync(openapiPath)) {
+  const file = fs.readFileSync(openapiPath, 'utf8');
+
+  // Parse the YAML content into a JavaScript object representing the Swagger document
+  const swaggerDocument = YAML.parse(file);
+
+  // Serve the Swagger UI documentation at the '/api-doc' endpoint
+  // This middleware serves the Swagger UI files and sets up the Swagger UI page
+  // It takes the parsed Swagger document as input
+  app.use('/api-doc', swaggerUi.serve, swaggerUi.setup(swaggerDocument));
+} else {
+  console.log("Not configuring OpenAPI. Configuration file not present.")
+}
+
+
 // Start the gateway service
 const server = app.listen(port, () => {
   console.log(`Gateway Service listening at http://localhost:${port}`);
 });
 
+
 module.exports = server