Skip to content

Commit

Permalink
Merge branch 'Develop' into FeatureQuestions
Browse files Browse the repository at this point in the history
  • Loading branch information
UO287687 committed Feb 22, 2024
2 parents d891e57 + b21f986 commit b359c9b
Show file tree
Hide file tree
Showing 39 changed files with 1,719 additions and 163 deletions.
2 changes: 1 addition & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -91,7 +91,7 @@ The deploy action is the following:
deploy:
name: Deploy over SSH
runs-on: ubuntu-latest
needs: [docker-push-userservice,docker-push-authservice,docker-push-gatewayservice,docker-push-webapp]
needs: [docker-push-userservice,docker-push-authservice,docker-push-gatewayservice,docker-push-webapp,docker-push-questiongenerationservice, docker-push-questionservice]
steps:
- name: Deploy over SSH
uses: fifsky/ssh-action@master
Expand Down
21 changes: 20 additions & 1 deletion docker-compose.yml
Original file line number Diff line number Diff line change
Expand Up @@ -48,6 +48,20 @@ services:
- "8003:8003"
networks:
- mynetwork

questionservice:
container_name: questionservice-${teamname:-defaultASW}
image: ghcr.io/arquisoft/wiq_es3b/questionservice:latest
profiles: ["dev", "prod"]
build: ./questionservice
depends_on:
- mongodb
ports:
- "8004:8004"
networks:
- mynetwork
environment:
MONGODB_URI: mongodb://mongodb:27017/questionsdb

gatewayservice:
container_name: gatewayservice-${teamname:-defaultASW}
Expand All @@ -59,6 +73,7 @@ services:
- userservice
- authservice
- questiongenerationservice
- questionservice
ports:
- "8000:8000"
networks:
Expand All @@ -67,6 +82,7 @@ services:
AUTH_SERVICE_URL: http://authservice:8002
USER_SERVICE_URL: http://userservice:8001
QUESTION_GENERATION_SERVICE_URL: http://questiongenerationservice:8003
QUESTIONS_SERVICE_URL: http://questionservice:8004

webapp:
container_name: webapp-${teamname:-defaultASW}
Expand All @@ -76,7 +92,10 @@ services:
depends_on:
- gatewayservice
ports:
- "3000:3000"
- "3000:3000"
#volumes:
#- ./webapp:/app


prometheus:
image: prom/prometheus
Expand Down
Binary file added docs/images/GameView.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/StartView.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/UserView.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
103 changes: 59 additions & 44 deletions docs/src/03_system_scope_and_context.adoc
Original file line number Diff line number Diff line change
@@ -1,75 +1,90 @@
ifndef::imagesdir[:imagesdir: ../images]

[[section-system-scope-and-context]]
== System Scope and Context
# System Scope and Context


[role="arc42help"]
****
.Contents
System scope and context - as the name suggests - delimits your system (i.e. your scope) from all its communication partners
(neighboring systems and users, i.e. the context of your system). It thereby specifies the external interfaces.
---

If necessary, differentiate the business context (domain specific inputs and outputs) from the technical context (channels, protocols, hardware).
## Contents
### Scope and context

.Motivation
The domain interfaces and technical interfaces to communication partners are among your system's most critical aspects. Make sure that you completely understand them.
This project aims to develop a quiz game.
The main constraints are developing the game as a web app and using Wikidata to obtain the questions and answers.

.Form
Various options:
---

* Context diagrams
* Lists of communication partners and their interfaces.
## Business Context

[role="arc42help"]

.Further Information
### Contents

See https://docs.arc42.org/section-3/[Context and Scope] in the arc42 documentation.
* *Users:* They interact directly with the application through the user interface provided by the frontend using React, HTML, CSS, and JavaScript.
* *Wikidata API:* The application communicates with the Wikidata service to obtain questions and answers related to different topics. Requests are made using the HTTP protocol, and response data is received in JSON format.

****
---

### Motivation

=== Business Context
Regarding the information exchanged with the application, it will require having a registered account to play, and it will also exchange information with a MongoDB database and Wikidata itself to obtain the questions.

[role="arc42help"]
****
.Contents
Specification of *all* communication partners (users, IT-systems, ...) with explanations of domain specific inputs and outputs or interfaces.
Optionally you can add domain specific formats or communication protocols.
---

.Motivation
All stakeholders should understand which data are exchanged with the environment of the system.
### Form

.Form
All kinds of diagrams that show the system as a black box and specify the domain interfaces to communication partners.
|===

Alternatively (or additionally) you can use a table.
The title of the table is the name of your system, the three columns contain the name of the communication partner, the inputs, and the outputs.
| *Quiz Game* | *Comunication Partners* | *Inputs* | *Outputs*
| Users | User Interface | User answers | Game questions
| Wikidata API | API Service | Question requests | JSON Responses

****
|===

**<Diagram or Table>**
---

**<optionally: Explanation of external domain interfaces>**
### Context diagram
[plantuml, "context", png]
----
component "App" as app
=== Technical Context
:User: -> [app]: Answer question
[app] -> User: Return result
[role="arc42help"]
****
.Contents
Technical interfaces (channels and transmission media) linking your system to its environment. In addition a mapping of domain specific input/output to the channels, i.e. an explanation which I/O uses which channel.
database DB
[app] -> DB: Ask for question
DB -> [app]: Return question
component "WikiData" as wd
[app] --> wd: Ask for keyword
wd --> [app]: Return keyword
----

.Motivation
Many stakeholders make architectural decision based on the technical interfaces between the system and its context. Especially infrastructure or hardware designers decide these technical interfaces.
---

## Technical Context

[role="arc42help"]

.Form
E.g. UML deployment diagram describing channels to neighboring systems,
together with a mapping table showing the relationships between channels and input/output.
### Contents

****
* *HTTP Channel:* The application uses the HTTP protocol to communicate with the Wikidata API service.
* *MongoDB Data Channel:* Interactions with the MongoDB database allow for storing and retrieving questions and answers.

**<Diagram or Table>**
---

**<optionally: Explanation of technical interfaces>**
### Deployment diagram
[plantuml, "deployment", png]
----
node "Aplication Server" as app
node "DB Server" as db {
artifact "MongoDB Server"
}
node Wikidata as w
node Interface as i
**<Mapping Input/Output to Channels>**
app - db
app -- w
app -- i
----
91 changes: 72 additions & 19 deletions docs/src/04_solution_strategy.adoc
Original file line number Diff line number Diff line change
@@ -1,32 +1,85 @@
ifndef::imagesdir[:imagesdir: ../images]

[[section-solution-strategy]]
== Solution Strategy

# Solution Strategy

[role="arc42help"]
****
.Contents
A short summary and explanation of the fundamental decisions and solution strategies, that shape system architecture. It includes
## Contents
This page contains a short summary and explanation of the fundamental decisions and solution strategies, that shape system architecture.

---

### Technology Decisions
Below, all the technologies to be used in the development of the application are listed:

* *JavaScript / React:* A JavaScript library designed to facilitate the development of web applications.
* *JavaScript / NodeJS:* An asynchronous runtime environment based on JavaScript.
* *MongoDB:* A document-oriented NoSQL database system.
* *Docker:* Used for deploying applications locally.
* *Azure:* Used for deploying applications on a server.

---

### Top-Level Decisions
In this section, a summarized list of all decisions regarding the architecture of the application is included.

|===

| *Architectural Pattern* | In this project, the pattern based on the Microservices model is used.
| *Frontend (Client)* | React: Building the user interface
| *Backend (Server)* | NodeJS: Building the server on the backend
| | Mongoose: Interaction with the database
| *Database* | MongoDB: NoSQL database storing data in BSON format
| *Deployment* | Azure cloud services

|===

---

### Quality Goals
Next, several quality goals are established, along with the decisions made to achieve them.

|===
| *Quality Goal* | *Decisions*

| Usability
| Creation of a responsive interface adaptable to all types of screens.

| Accessibility
| Compliance with accessibility standards to ensure a usable application.

| Maintainability
| A structured project that facilitates the maintainability of the application.

| Testing
| Assurance of a fully functional and error-free application.

|===

---

### Relevant Organizational
Regarding the organization of the team, we have decided to use agile methodologies for better and faster group work. In this project, we will follow the best practices of the SCRUM framework.

* technology decisions
* decisions about the top-level decomposition of the system, e.g. usage of an architectural pattern or design pattern
* decisions on how to achieve key quality goals
* relevant organizational decisions, e.g. selecting a development process or delegating certain tasks to third parties.
Practices to be followed:

.Motivation
These decisions form the cornerstones for your architecture. They are the foundation for many other detailed decisions or implementation rules.
* Division of the project into *tasks*.
* Equitable *assignment* of tasks.
* Frequent *meetings* on the progress of the application.
* Construction of *"Alpha"* versions before the final release.

.Form
Keep the explanations of such key decisions short.
Additionally, "Issues" and the GitHub-provided Kanban (ToDo - In Progress - Done) are used for communication.

Motivate what was decided and why it was decided that way,
based upon problem statement, quality goals and key constraints.
Refer to details in the following sections.
---

### Motivation
This section addresses the fundamental decisions for the project's architecture.

.Further Information
|===

See https://docs.arc42.org/section-4/[Solution Strategy] in the arc42 documentation.
| *Data Management* |
| *Deployment* |
| *Security* |
| *Monitoring* |

****
|===
12 changes: 12 additions & 0 deletions gatewayservice/gateway-service.js
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,7 @@ const port = 8000;
const authServiceUrl = process.env.AUTH_SERVICE_URL || 'http://localhost:8002';
const userServiceUrl = process.env.USER_SERVICE_URL || 'http://localhost:8001';
const questionGenerationServiceUrl = process.env.QUESTION_GENERATION_SERVICE_URL || 'http://localhost:8003';
const questionServiceUrl = process.env.QUESTIONS_SERVICE_URL || 'http://localhost:8004';

app.use(cors());
app.use(express.json());
Expand Down Expand Up @@ -52,6 +53,17 @@ app.get('/api/questions/create', async (req, res) => {
}
});

// Ruta para agregar una nueva pregunta
app.post('/addquestion', async (req, res) => {
try {
// Forward the add question request to the questions service
const questionResponse = await axios.post(questionServiceUrl + '/addquestion', req.body);
res.json(questionResponse.data);
} catch (error) {
res.status(error.response.status).json({ error: error.response.data.error });
}
});

// Start the gateway service
const server = app.listen(port, () => {
console.log(`Gateway Service listening at http://localhost:${port}`);
Expand Down
Loading

0 comments on commit b359c9b

Please sign in to comment.