About arc42

arc42, the template for documentation of software and system architecture.

Template Version 8.2 EN. (based upon AsciiDoc version), January 2023

Created, maintained and © by Dr. Peter Hruschka, Dr. Gernot Starke and contributors. See https://arc42.org.

Note

This version of the template contains some help and explanations. It is used for familiarization with arc42 and the understanding of the concepts. For documentation of your own system you use better the plain version.

1. Introduction and Goals

Describes the relevant requirements and the driving forces that software architects and development team must consider. These include

  • underlying business goals,

  • essential features,

  • essential functional requirements,

  • quality goals for the architecture and

  • relevant stakeholders and their expectations

    • new elements

ChattySw has been hired by RTVE to improve an online quiz game inspired by "Saber y Ganar." The previous version was developed by HappySw.

The new version, WIChat, lets users identify locations from images and answer related questions. A key feature is the ability to get hints through a conversational AI model.

1.1. Requirements Overview

Contents

Short description of the functional requirements, driving forces, extract (or abstract) of requirements. Link to (hopefully existing) requirements documents (with version number and information where to find it).

Motivation

From the point of view of the end users a system is created or modified to improve support of a business activity and/or improve the quality.

Form

Short textual description, probably in tabular use-case format. If requirements documents exist this overview should refer to these documents.

Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents.

Further Information

See Introduction and Goals in the arc42 documentation.

  • Users must be able to register, log in, and manage their accounts.

  • The system must present images and corresponding quiz questions.

  • Users must be able to submit answers within a set time limit.

  • A conversational AI must provide hints when requested.

  • The system must track user performance and maintain historical data.

  • Questions, answers, and hints must be generated automatically from Wikidata.

  • APIs must be available for accessing user data and quiz content.

1.2. Quality Goals

Contents

The top three (max five) quality goals for the architecture whose fulfillment is of highest importance to the major stakeholders. We really mean quality goals for the architecture. Don’t confuse them with project goals. They are not necessarily identical.

Consider this overview of potential topics (based upon the ISO 25010 standard):

Categories of Quality Requirements
Motivation

You should know the quality goals of your most important stakeholders, since they will influence fundamental architectural decisions. Make sure to be very concrete about these qualities, avoid buzzwords. If you as an architect do not know how the quality of your work will be judged…​

Form

A table with quality goals and concrete scenarios, ordered by priorities

Quality Goal Description

Reliability

Ensure that the generated questions and hints are accurate and relevant.

Scalability

Support a growing number of users and interactions.

Usability

Provide an intuitive and engaging user experience.

Maintainability

Allow easy updates and improvements to the system.

Security

Protect user data and ensure fair gameplay.

Performance

It will work the 95% of the time excluding maintenance periods

1.3. Stakeholders

Contents

Explicit overview of stakeholders of the system, i.e. all person, roles or organizations that

  • should know the architecture

  • have to be convinced of the architecture

  • have to work with the architecture or with code

  • need the documentation of the architecture for their work

  • have to come up with decisions about the system or its development

Motivation

You should know all parties involved in development of the system or affected by the system. Otherwise, you may get nasty surprises later in the development process. These stakeholders determine the extent and the level of detail of your work and its results.

Form

Table with role names, person names, and their expectations with respect to the architecture and its documentation.

Name Description Expectations

Development Team

The development team consists of the students that are members of the group.

They should develop a robust application and learn new technologies.

ChattySw

The company responsible for developing the application.

They should develop a satisfactory product efficiently and cost-effectively.

RTVE

The entity responsible for hiring the application development.

They should obtain the best possible product.

Registered Users

Any person using the application.

They expect to enjoy a great user experience and learn from the quiz questions.

Admin Users

The application would need some administrator to fix any strange behaviour in game.

They expect to fix some minor problems.

HappySw

Competitor to ChattySw, developer of the previous version of the application.

They should compete with ChattySw as the developer of the previous version of the application.

Rest of competitors

There is more than one competitor to that type of games.

They compete with ChattySW and WiChat on engaging the target audience of the game.

Hosting suppliers - Azure

The application must be deployed for the public use

They expect a new client of their services.

DNS suppliers

The application must be found in the web by a domain of RTVE

They expect a new client of their services.

Saber y Ganar

The physical version of the game would dictate the rules of its online version

It expects to have similar functions as this online game.

2. Architecture Constraints

Contents

Any requirement that constraints software architects in their freedom of design and implementation decisions or decision about the development process. These constraints sometimes go beyond individual systems and are valid for whole organizations and companies.

Motivation

Architects should know exactly where they are free in their design decisions and where they must adhere to constraints. Constraints must always be dealt with; they may be negotiable, though.

Form

Simple tables of constraints with explanations. If needed you can subdivide them into technical constraints, organizational and political constraints and conventions (e.g. programming or versioning guidelines, documentation or naming conventions)

Further Information

See Architecture Constraints in the arc42 documentation.

2.1. Motivation

Constraints, like building codes, budgets, or client needs, must always be considered, but some can be adjusted through discussion or smart solutions. Every decision that collide with the constraints decided will be discussed with the team.

2.2. Technical constraints

Constraint

Explanation

Javascript

The programming language of the project is Javascript, in order to take advantage of some of the frameworks available.

React

The use of React.js framefork for the frontend.

Node

The use of Node.js framework for the backend.

Express

A framework used by Node.js in order to make a structure for application witout a huge complexity.

MongoDB

The database will be MongoDb, a NoSQL database system.

Wikidata

It will be used to generate questions.

Github

All the shares information will be stored at the repo of the project.

LLM integration

As the system gives hints to the players, a way of comunicating with a LLM (Long Language Model) sush as Gemini or Mistral is needed.

Docker

In order to deploy all the services and make them accesible online, Docker will be used to ease and automate the deployment process.

APIs usage

Some of the services will work as an Application Programming Interface.

Time mangement

In order to have a complete experience while using the app, timeouts and timers are needed.

2.3. Organizational constraints

Constraint

Explanation

P2P Review

Every branch for the development will have two roles, the developer and the reviewer, using one of the features of Github, Pull Requests.

Issues

As the project is held in Github, Github issues are the best way to track all the tasks that need to be done.

Meeting reports

Every time the development team have a meeting to discuss something related with the project.

Self reports

By the end of every sprint, each member has to open an issue to write down what they have done over the sprint, as well as the complications they have found while developing.

Timelines

As the project has a final deadline, evrything would be finished by May 5th and will not recieve any update after that day.

Azure budget cap

As deployment is a mandatory function of the final result, the team have to deal with the budget cap given by Azure as students.

2.4. Conventions

Constraint

Explanation

Use of English

The documentation will be all written in English as it is the "software-related" language all over the world.

Arch42

The documentation will follow the Arch42 template as a way to split and order all the information related with the software product.

3. Context and Scope

3.1. Business Context

Communication Partner Inputs Outputs

Client

Username, password

Game score, questions retrieved from Wikidata

Database

Username, password, score of each game

Credential validation, score storage

Wikidata

Request for information about the game question

Generated question with relevant information

Empathy/Gemini

Game question and correct answer

Hints to help the user answer better
Diagram Business Context

3.2. Technical Context

Technology

Description

Database

MongoDB

Communication with Empathy/Gemini

HTTP

User Interface

React

Server

Node.js

Virtual Machine

Azure
Diagram technical Context

Channels

Type

Input/Output

HTTP/REST

Output

WICHAT → User API

HTTP/REST

Output

WICHAT → Question API

HTTP/REST

Input

WICHAT → Wikidata

HTTP/REST

Input

WICHAT → llm

HTTP

Input

wichat → Database

HTTP

Output

WICHAT → Database

4. Solution Strategy

4.1. Technology Decisions

To develop the application, we have decided to use the following technologies which were the ones provided in the base project:

  • JavaScript: will be the programming language used in the project. We chose it for its widespread popularity, broad browser support, and robust ecosystem(It has a wide variety of tools, libraries, frameworks, and an active community), making it ideal for both frontend and backend development with Node.js.

  • ReactJS: allows us to build user interfaces; its component-based architecture and excellent performance make it ideal for web applications like ours. Furthermore, its seamless integration with JavaScript was a key factor in our decision.

  • Docker: We will use Docker to deploy the web application, as this platform allows us to create containers that package the application and its dependencies, ensuring consistent performance and simplifying deployment across different environments. Additionally, Docker facilitates isolated testing, ensuring that the application runs the same way in each environment (development, testing, production) without external interference.

  • GitHub: is used as a version control and collaboration platform, allowing the team to work efficiently and . Additionally, GitHub Actions provides continuous integration and continuous deployment and organized, as tools from GitHub are used, such as pull requests (to review the code before uploading and avoid conflicts) and issues (to track what each team member is doing or has done).

  • WikiData: will be used as a source of structured data, providing access to large volumes of open data that can be easily integrated into the application.

  • EspressJS: is a minimal and flexible framework for Node.js that simplifies the creation of web applications and APIs. Its simplicity and large ecosystem of middleware(intermediaries between the server and the application,they can perform tasks such as authentication, handling HTTP requests, data validation, logging, among others.) make it ideal for developing the backend of our application.

  • MongoDB was selected as our database due to it’s scalability and flexibility in handling data. As a non-relational database, it allows for more dynamic and adaptable data storage and retrieval compared to traditional relational databases like MySQL. While MySQL provides structured query language and consistency, MongoDB offers greater flexibility, making it more suitable for our application’s needs, especially when dealing with large volumes of unstructured or semi-structured data, such as the data from WikiData used for questions and answers.

4.2. Top-Level Descomposition

We have chosen to adopt a microservices architecture because we believe it is the best approach for our project. In this design paradigm, the application is segmented into small, autonomous services that typically interact via APIs.Currently, we have the following microservices:

  • Authentication service: It is used for user authentication.

  • Question service: It is used to generate questions from the Wikidata API.

4.3. Approaches to Achieve Top Quality Goals

Quality Goal Decision Made

Usability

We use ReactJS to build an interactive and modern user interface. Additionally, we follow UX/UI design principles to enhance the user experience.

Security

The application should protect user data and prevent unauthorized access.

Scalability

We use Docker and microservices to enable independent deployment and scalability of each system component. MongoDB facilitates horizontal scalability.

Testability

We apply unit and integration testing. Additionally, we use GitHub Actions for automated testing on each push.

Adaptability

We want our application to reach more people, therefore, we need to make it adaptable to different devices such as mobile phones, laptops, etc., in order to provide the best possible user experience.

Maintainability

The code should be easy to understand, modify, and extend to facilitate future improvements and allow any new team member to comprehend it without issues. To achieve this, we will implement proper documentation that explains key architectural decisions, the project’s functionality, among other aspects. We will also use GitHub, as version control allows tracking the changes made by each team member. Additionally, we will apply modularization, breaking the code into small, reusable and isolated functions and modules.

Performance

To improve the application’s performance and avoid system overload, we will use the minimum number of API calls possible to reduce response time.

4.4. Organizational Decision

  • Language: We have chosen English as the language for this project, which will make it accessible to everyone.

  • GitHub Projects: We will use it to track the team’s work in general and in a more visual way.

  • Meetings: We will hold them weekly during the lab class, except on special occasions when key decisions for the application need to be made.

  • Tasks: each task assigned to a member must be associated with an issue to track what each member has done or is currently doing

Contents

A short summary and explanation of the fundamental decisions and solution strategies, that shape system architecture. It includes

  • 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.

Motivation

These decisions form the cornerstones for your architecture. They are the foundation for many other detailed decisions or implementation rules.

Form

Keep the explanations of such key decisions short.

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.

Further Information

See Solution Strategy in the arc42 documentation.

5. Building Block View

Content

The building block view shows the static decomposition of the system into building blocks (modules, components, subsystems, classes, interfaces, packages, libraries, frameworks, layers, partitions, tiers, functions, macros, operations, data structures, …​) as well as their dependencies (relationships, associations, …​)

This view is mandatory for every architecture documentation. In analogy to a house this is the floor plan.

Motivation

Maintain an overview of your source code by making its structure understandable through abstraction.

This allows you to communicate with your stakeholder on an abstract level without disclosing implementation details.

Form

The building block view is a hierarchical collection of black boxes and white boxes (see figure below) and their descriptions.

Hierarchy of building blocks

Level 1 is the white box description of the overall system together with black box descriptions of all contained building blocks.

Level 2 zooms into some building blocks of level 1. Thus it contains the white box description of selected building blocks of level 1, together with black box descriptions of their internal building blocks.

Level 3 zooms into selected building blocks of level 2, and so on.

Further Information

See Building Block View in the arc42 documentation.

5.1. Whitebox Overall System

Here you describe the decomposition of the overall system using the following white box template. It contains

  • an overview diagram

  • a motivation for the decomposition

  • black box descriptions of the contained building blocks. For these we offer you alternatives:

    • use one table for a short and pragmatic overview of all contained building blocks and their interfaces

    • use a list of black box descriptions of the building blocks according to the black box template (see below). Depending on your choice of tool this list could be sub-chapters (in text files), sub-pages (in a Wiki) or nested elements (in a modeling tool).

  • (optional:) important interfaces, that are not explained in the black box templates of a building block, but are very important for understanding the white box. Since there are so many ways to specify interfaces why do not provide a specific template for them. In the worst case you have to specify and describe syntax, semantics, protocols, error handling, restrictions, versions, qualities, necessary compatibilities and many things more. In the best case you will get away with examples or simple signatures.

Motivation

The system consists of a game (Saber y ganar) in which the user interacts with the application to answer questions.

Contained Building Blocks
Name Responsibility

Usuario

Interacts with the application via the frontend.

Frontend (React)

Provides the user interface where users interact with the system.

Backend (Node.js)

Manages business logic, handles frontend requests, and communicates with the database.

MongoDB

NoSQL database used for storing user, race, and registration data.

Docker

Containerization platform ensuring portability and scalability of services.

6. Runtime View

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 Runtime View in the arc42 documentation.

6.1. User Registration

registration

6.2. User Login

login

6.3. Question Generation

question generation

6.4. Answering a Question

question response

6.5. Ranking Query

ranking

7. Deployment View

Content

The deployment view describes:

  1. technical infrastructure used to execute your system, with infrastructure elements like geographical locations, environments, computers, processors, channels and net topologies as well as other infrastructure elements and

  2. mapping of (software) building blocks to that infrastructure elements.

Often systems are executed in different environments, e.g. development environment, test environment, production environment. In such cases you should document all relevant environments.

Especially document a deployment view if your software is executed as distributed system with more than one computer, processor, server or container or when you design and construct your own hardware processors and chips.

From a software perspective it is sufficient to capture only those elements of an infrastructure that are needed to show a deployment of your building blocks. Hardware architects can go beyond that and describe an infrastructure to any level of detail they need to capture.

Motivation

Software does not run without hardware. This underlying infrastructure can and will influence a system and/or some cross-cutting concepts. Therefore, there is a need to know the infrastructure.

Form

Maybe a highest level deployment diagram is already contained in section 3.2. as technical context with your own infrastructure as ONE black box. In this section one can zoom into this black box using additional deployment diagrams:

  • UML offers deployment diagrams to express that view. Use it, probably with nested diagrams, when your infrastructure is more complex.

  • When your (hardware) stakeholders prefer other kinds of diagrams rather than a deployment diagram, let them use any kind that is able to show nodes and channels of the infrastructure.

Further Information

See Deployment View in the arc42 documentation.

7.1. Infrastructure Level 1

Describe (usually in a combination of diagrams, tables, and text):

  • distribution of a system to multiple locations, environments, computers, processors, .., as well as physical connections between them

  • important justifications or motivations for this deployment structure

  • quality and/or performance features of this infrastructure

  • mapping of software artifacts to elements of this infrastructure

For multiple environments or alternative deployments please copy and adapt this section of arc42 for all relevant environments.

Vista de despliegue
Motivation

Having independent services deployed on the same machine give a lot of flexibility at deciding where the application will be deployed, making possible to have only a virtual machine to run the whole application.

Quality and/or Performance Features

By our experience, we estimate that Azure VM with 2 GiB RAM and 1vCPU could work perfectly.

Mapping of Building Blocks to Infrastructure

Element

Description

Client

The client will always be a web browser such as Safari or Firefox, by a HTTP request.

WebApp

This is the frontend of the application. THe function of the game does not need to store information, everything is dynamic, so there is no need is having the game in an independent service.

Gateway

The gateway service contain all the information required to users: their account, the scores they had and so on. These modules connect to the same database, a mongoDB located at the same machine as the application, but not being part of it.

Questions

This service connects with de Wikidata API, and requests some types of questions known by our application.

Wikidata

Service where questions are collected. SparQL is required to use the API

LLM

The LLM decided to support hint requests are Mistral and Gemini. The idea is to give a prompt with the context of how to answer client questions with hints.

Every interaction between services is done by HTTP requests, and they have defined their own ports on the same machine:

Element

Port

Webapp

3000

Gateway Service

8000

User Service

8001

Auth Service

8002

LLM Service

8003

History Service

8004

Questions Service

8010

WebApp

3000

8. Design Concepts and Decisions

8.1. Architectural Patterns and Principles

The system follows a microservices architecture, ensuring modularity and scalability:

Service Layering:

Independent Services: Each microservice is responsible for a specific domain, handling its own data and business logic. API Gateway: Manages communication between services and external clients, ensuring secure and efficient data flow. Frontend Integration: The user interface consumes APIs from multiple microservices, allowing for a flexible and decoupled design. This approach enhances scalability, maintainability, and component reusability, facilitating independent development and deployment of services.

8.2. Key Architectural Decisions

Starting from Scratch with Reference to Previous Projects: The decision was made to develop the system from scratch, leveraging the knowledge and experiences from last year’s projects. This allowed for the design of a more efficient and flexible architecture without the constraints of previous versions.

Use of Modern Technologies: Technologies such as React for the interface, Node.js for the backend, and MongoDB as the database have been chosen, ensuring an agile development process adaptable to the project’s needs.

As development progresses, more key decisions and their justifications will be documented.

9. Architecture Decisions

Contents

Important, expensive, large scale or risky architecture decisions including rationales. With "decisions" we mean selecting one alternative based on given criteria.

Please use your judgement to decide whether an architectural decision should be documented here in this central section or whether you better document it locally (e.g. within the white box template of one building block).

Avoid redundancy. Refer to section 4, where you already captured the most important decisions of your architecture.

Motivation

Stakeholders of your system should be able to comprehend and retrace your decisions.

Form

Various options:

  • ADR (Documenting Architecture Decisions) for every important decision

  • List or table, ordered by importance and consequences or:

  • more detailed in form of separate sections per decision

Further Information

See Architecture Decisions in the arc42 documentation. There you will find links and examples about ADR.

The architectural decisions are fully documented in our repository Wiki Section. To avoid redundancy, instead of writing the decisions here in the documentation, we will refer o them.

9.1. Architectural Decisions

9.1.1. Organizational Decisions

9.1.2. Technology Decisions

9.1.3. Top-Level Descomposition

10. Quality Requirements

Content

This section contains all quality requirements as quality tree with scenarios. The most important ones have already been described in section 1.2. (quality goals)

Here you can also capture quality requirements with lesser priority, which will not create high risks when they are not fully achieved.

Motivation

Since quality requirements will have a lot of influence on architectural decisions you should know for every stakeholder what is really important to them, concrete and measurable.

Further Information

See Quality Requirements in the arc42 documentation.

Motivation

"As quality requirements, we aim to meet our quality objectives: usability, maintainability, efficiency, testability, portability."

Usability

The application must be easy to use and allow intuitive interaction. Priority: High

Maintainability

The application must be easy to modify and extend without breaking functionality. Priority: High

Efficiency

The application must perform optimally, minimizing resource and time usage. Priority: Medium

Testability

The application must be easy to test to ensure quality and detect errors. Priority: High

Portability

The application must run on different platforms for better adaptability. Priority: Medium

11. Specific Requirements

Specific Requirements

  • ❏ The system must store user registration data.

  • ❏ The system must correctly validate answers to questions.

  • ❏ The system must not allow modification of question results once answered.

  • ❏ The system must inform the user of possible errors through a message.

  • ❏ The system must notify the user when they have answered a question correctly or incorrectly and when their time has run out.

12. Risks and Technical Debts

Contents

A list of identified technical risks or technical debts, ordered by priority

Motivation

“Risk management is project management for grown-ups” (Tim Lister, Atlantic Systems Guild.)

This should be your motto for systematic detection and evaluation of risks and technical debts in the architecture, which will be needed by management stakeholders (e.g. project managers, product owners) as part of the overall risk analysis and measurement planning.

Form

List of risks and/or technical debts, probably including suggested measures to minimize, mitigate or avoid risks or reduce technical debts.

Further Information

See Risks and Technical Debt in the arc42 documentation.

Risk Explanation Measure

Lack of experience with the technologies used

We lack extensive experience with technologies like React, Node.js, MongoDB, which might complicate their usage.

Research these technologies and learn how to use them correctly.

Lack of time

There are deadlines for each deliverable, and we may run out of time.

Stay consistent and do as much as possible daily.

Teamwork challenges

Working in a team can be difficult, especially since we’ve never done a large project like this.

Maintain good communication and collaboration.

Unproductive meetings

Spending too much time in meetings without making progress can cause issues.

Prepare briefly for meetings to focus on specific topics.

Member abandonment

If a team member quits, their tasks will need to be reassigned, increasing the workload.

Assign tasks to multiple people and offer support to avoid abandonment.

External service failure

An external service like Wikidata or Azure may fail temporarily.

Stay updated on service changes and work to restore functionality quickly.
Technical Debt Explanation Solution

Insufficient documentation

Lack of proper documentation can make future system understanding and maintenance challenging.

Ensure thorough and clear documentation is created.

Suboptimal database design

A poorly designed database can create scalability issues as the system grows.

Plan and design the database carefully before implementation or modification.

Dependence on AI-generated code

AI-generated code may have inaccuracies, potentially leading to difficulties when revisiting or updating it.

Review, adjust, and validate AI-generated code before integration.

LLM performance issues

The language model may cause slow response times and irrelevant answers, impacting user experience.

Optimize prompts and continuously monitor the model’s performance for improvements.

13. Glossary

Contents

The most important domain and technical terms that your stakeholders use when discussing the system.

You can also see the glossary as source for translations if you work in multi-language teams.

Motivation

You should clearly define your terms, so that all stakeholders

  • have an identical understanding of these terms

  • do not use synonyms and homonyms

Form

A table with columns <Term> and <Definition>.

Potentially more columns in case you need translations.

Further Information

See Glossary in the arc42 documentation.

Term Definition

React.js

It is a free and open-source front-end JavaScript library that aims to make building user interfaces based on components more "seamless".

Node.js

Node.js is a cross-platform, open-source JavaScript runtime environment that can run on Windows, Linux, Unix, macOS, and more. Node.js runs on the V8 JavaScript engine, and executes JavaScript code outside a web browser.

MongoDB

MongoDB is a source-available, cross-platform, document-oriented database program. Classified as a NoSQL database product, MongoDB uses JSON-like documents with optional schemas.

LLM

A large language model (LLM) is a type of machine learning model designed for natural language processing tasks such as language generation. LLMs are language models with many parameters, and are trained with self-supervised learning on a vast amount of text.

Microservices

A microservice architecture is an architectural pattern that organizes an application into a collection of loosely coupled, fine-grained services that communicate through lightweight protocols. This pattern is characterized by the ability to develop and deploy services independently, improving modularity, scalability, and adaptability.

Docker

Containers are isolated from one another and bundle their own software, libraries and configuration files; they can communicate with each other through well-defined channels. Because all of the containers share the services of a single operating system kernel, they use fewer resources than virtual machines.

SSH

The Secure Shell Protocol (SSH Protocol) is a cryptographic network protocol for operating network services securely over an unsecured network. Its most notable applications are remote login and command-line execution.

14. About the game

Term Definition

Hint Chat - WiChat AI

The hint chat is referred to the chat where the players can comunicate with the LLM in order to get information about the correct answer

WiChat

WiChat is the name of the whole project and the application.

Ranking

The ranking page is referred to an online leaderboard of who got the most points overall.

Category

Although is not shown yet, categories are referred to the type of questions the game has. This can be expanded or filtered as needed.

Time

Each question has its own time of answering, that could be use in several game modes.