docs/jjgancfer

.vscode/settings.json

@@ -0,0 +1 @@
+{}

docs/src/04_solution_strategy.adoc

@@ -3,30 +3,46 @@ ifndef::imagesdir[:imagesdir: ../images]
 [[section-solution-strategy]]
 == Solution Strategy
 
+What follows is a summary of our solution's main decisions, and the approach we decided to use to create the system. 
 
-[role="arc42help"]
-****
-.Contents
-A short summary and explanation of the fundamental decisions and solution strategies, that shape system architecture. It includes
+=== Technologies breakdown
 
-* 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.
+Regarding the technologies, we decided to use the following ones:
 
-.Motivation
-These decisions form the cornerstones for your architecture. They are the foundation for many other detailed decisions or implementation rules.
+ * **React** for the frotend, using the **Chakra UI** component library. Although the preferred way to use React is currently through a framework, we preferred this approach due to this being many of us first time using it, as well as a lack of experience using any framework in any of us.
 
-.Form
-Keep the explanations of such key decisions short.
+ ** As a consecuence of this, pure JavaScript is being used due to React 18 not supporting Typescript 5.
 
-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.
+ * **PostgreSQL** as DBMS to store the information. We nearly immediately discarded using MongoDB due to many of us not having experience with it, and those that did preferring SQL. Many modern DBMS also include either JSON or JSONB data types, so using a DBMS whose main appeal is JSON and not many of us have experience with did not sit well with us.
 
+ * **Java SpringBoot** for the backend/API, it being a language we are all comfortable with. The server will easily support multithreading if needed due to SpringBoot being an abstraction over servlets, something we would be able only to simulate if we used Node.js as it uses a single-threaded event loop.
 
-.Further Information
+=== Organizational breakdown 
 
-See https://docs.arc42.org/section-4/[Solution Strategy] in the arc42 documentation.
+Currently, we have been meeting twice a week, but that may change in the future. Most, if not all of us, were present for these meetings, and relevant decisions were also discussed on the side and between members, as well discussions related to opinions on some matter. Some of these meetings took place in person while others took place on a Discord Server.
 
-****
+We also have a Whatsapp community for the team, and a Notion wiki.
+
+=== Important quality-related decisions
+
+|===
+|*Quality attribute pursued*|*Solution chosen*
+|Privacy|All stored password will be hashed, both client-side and server-side, to avoid password disclosure. The client-side password is also intended to prevent password discoverage in case it is a repeated one.
+|Robustness|Currently, all validations will take place server-side to avoid not being properly taken care of due to JavaScript desactivation, such as when using the NoScript plug-in
+|Speed|Since Wikidata has a 1 minute limit related to the API, the backend will start querying it upon start and fill the database with questions to increase speed and thus improve user experience|
+|===
+
+=== Workflow
+
+We have divided ourselves in teams related to our own areas of expertise, but those divisions are indicative, and frontend teams may review or comment PRs if they wish, or vice versa. The frontend team may also ask input from the backend team if they wish, and the backend team may do the same.
+
+All in all, we strive to achieve a very flexible workflow in which everyone's input may be considered if they wish to give it.
+
+=== Code Style
+
+Regarding the code style, we must make two important distinctions: the frontend and backend. In the latter, we will mainly use Object Oriented Programming because our language of choice is Java, which strongly favours it. Regarding the former, it will be more of a case-by-case approach, as for instance, OOP-oriented React is deprecated in favor of a functional approach, but sometimes we may need OOP's strengths.
+
+ * In the backend, the structure will that of a typical Maven project.
+ * In the frontend, the structure will be quite different:
+ ** The `src/components` will be contain single components which we may reuse.
+ ** The `src/pages` will contain the endpoints and will follow a simple structure. For instance, given a `/statistics/personal` and a `/statistics/general` endpoints, both will be independent React components that will return the page and be placed under the `src/pages/statistics` folder.

docs/src/07_deployment_view.adoc

@@ -2,93 +2,39 @@ ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-deployment-view]]
 
-
 == Deployment View
 
-[role="arc42help"]
-****
-.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 https://docs.arc42.org/section-7/[Deployment View] in the arc42 documentation.
-
-****
+image::DeploymentDiagram.png[align="center",title="Deployment Diagram",link="DeploymentDiagram.png]
 
 === Infrastructure Level 1
 
-[role="arc42help"]
-****
-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.
-****
-image::DeploymentView.png[align="center",title="Deployment View",link="DeploymentView.png]
-_**<Overview Diagram>**_
-
 Motivation::
 
-_<explanation in text form>_
+The above diagram shows the initial version of the architecture and the division between its components. We will be using a simple client-server architecture, and the server will be querying Wikidata for the questions. By separating the architecture in this way we enforce a clear separation between the client/frontend and the server/backend, which benefits the system as a whole because so long the common API is implemented, the implementations themselves shall remain interchangeable.
 
 Quality and/or Performance Features::
 
-_<explanation in text form>_
+As stated before, we consider the main advantage of this architecture the interchangeability of the components. There remain details to be scratched out though, but this is still an initial version.
 
 Mapping of Building Blocks to Infrastructure::
-_<description of the mapping>_
 
+ * The webapp/frontend/client is contained within the `webapp` subfolder.
+ * The API/backend is contained within the `api` subfolder.
+ ** The database will be generated on deployment.
+ ** Wikidata is an external component, so although it is an important part of the deployment architecture, it is something we do not have access to changing.
 
 === Infrastructure Level 2
 
-[role="arc42help"]
-****
-Here you can include the internal structure of (some) infrastructure elements from level 1.
-
-Please copy the structure from level 1 for each selected element.
-****
-
-==== _<Infrastructure Element 1>_
+==== Frontend/Client
 
-_<diagram + explanation>_
+This component is self-contained and does not require much explanation.
 
-==== _<Infrastructure Element 2>_
+==== API/Backend
 
-_<diagram + explanation>_
+===== Server
 
-...
+Our main idea is that the server will be a self-contained .jar file with all the dependencies required within. It will communicate with the database and periodically query Wikidata to generate questions until a certain number has been obtained once per minute to fill up the database and improve speed.
 
-==== _<Infrastructure Element n>_
+===== Database
 
-_<diagram + explanation>_
+The database will contain the data used by the system. Therefore, it will contain user data and questions and their answers.