generated from Arquisoft/wiq_0
-
Notifications
You must be signed in to change notification settings - Fork 3
ADRS
Luna edited this page Mar 21, 2024
·
9 revisions
- ADR 01 - JavaScript
- ADR 02 - QG Microservice
- ADR 03 - Docker
- ADR 04 - React
- ADR 05 - MongoDB
- ADR 06 - ExpressJS
- ADR 07 - TBD
Using JavaScript to code the application's frontend and backend
✔️ Accepted
- It's an interpreted lightweight programming language, which cuts down on the time needed for compilation.
- It's simple to learn and versatile
- The team hasn't used JavaScript a lot so learning new things will be needed
- Poor debugging
- Using other frontend technologies: This would not be fit for our project since it is possible that compatibility issues may arise due to JavaScript being the main most use frontend technology to Date.
- Using other backend technologies: Php still is the most used backend technology in 2024, but using nodejs will definetely reduce costs and times as it decreases research and documentation tasks for the general purpose developers (the whole team).
- Developing a desktop/local app instead of a web-based system: This would definetely eliminate the deployment hell web apps involve, but a web app will provide a more consistent user base due to the web's ease of access and the tools each client's navigator include.
Creating a new microservice for the question generation service.
✔️ Accepted
- The architectural design of the project gets severly improved.
- The service becomes easier to reuse, maintain and scale.
- A new service will need to be created (implying all the work related).
- Implementing it in an already existing service: This would not make much sense because there are no actual alternatives were the new functionality fits properly.
Using Docker to deploy the application.
✔️ Accepted
- Fast and easy deployment.
- Requires little active memory to run.
- Outdated documentation.
- Switching to docker from other virtual machines can be difficult.
- No alternatives are took into account as we consider docker to be a modern deployment standard for web apps.
Using React JS to make the user interfaces of the application.
✔️ Accepted
- Component-Based Architecture, allowing to update parts of a webpage individually.
- Versatility and enhanced customization.
- Complex concepts and advanced patterns to learn.
- Substantial library and dependency requirements.
- Using Javascript natively: This will take too much effort, time, sweat and tears. Also the frontend will look nicer 😇.
- Other Javascript frameworks: The base project already uses react and also other frameworks do not have such a big community as react does, so they don't feel like good alternatives either.
Using MongoDB to store the data for the application
✔️ Accepted
- High speed and availability
- Simple query syntax
- It is the first time the teams uses a NonSql database for a project
- Joining documents can be a tedious task
- Using other types of databases: even though we have more knowledge of relational databases, a document database has a flexible schema, making it a practical solution to online user profiles by storing the attributes that are specific to each user.
Using ExpressJS for the application's backend
✔️ Accepted
- Simple and flexible
- It's new for the team so it will need research
- Lacks structure or convention for organizing your code
- No alternatives were suggested as ExpressJS is one of the most popular framweorks for building web applications and it's simple and quick to link with databases, such as MongoDB.
Changing from Gitflow to Trunk Based Development
✔️ Accepted
- More centralized development.
- Trying new team techniques.
- It will take some practice to fully understand how to sync our work properly
- Gitflow: Too many branches.