Architectural Decision 00 - Documentation Language

Option under discussion: English to be used as the language for documentation and the project..

✅ Pros:

*Global Reach - English is the universal language, so it can be understood by almost everyone.

❌ Cons:

*more effort to write the documentation.

🔄 Alternatives:

*Use any other language like Spanish, Chinese...

Status: Approved ✅

Architectural Decision 01 - Programming Language

Option under discussion: Use JavaScript for both frontend and backend.

✅ Pros:

• Low Learning Curve -> is relatively easy to learn compared to other programmin languages as it's straightforward syntax and extensive learning resources makes it easy make it easy to get started.
• Dynanism and Flexibility -> As interpreted and dynamic language, JavaScript allows for rapid prototyping and agile code modifications during development.
• Versatility -> It enables development on both the client(frontend) and server(backend) sides, allowing you to build full-stack applications using a single language.
• Vast Ecosystem and Community -> There is a wide variety of frameworks, libraries, and tools (such as React and Node.js) that facilitate development. In addition, its active community provides abundant documentation, tutorials, and support.

❌ Cons:

• Lack of Strict Typing -> It's weakly-typed nature can lead to runtime errors.
• JavaScript's dynamic nature can make code maintenance and refactoring more complex.
• Limited debugging capabilities, leading to longer troubleshooting and bug-fixing times.

🔄 Alternatives:

• Python: Excellent for backend development with frameworks like Django and Flask, but lacks native frontend capabilities, requiring additional tools for web development.
• Ruby on Rails: A robust backend option, but less commonly used for full-stack JavaScript projects, making integration more complex.
• TypeScript -> Has a steeper learning curve compared to JavaScript, mainly due to the need to understand additional concepts like static typing, interfaces, and generics. . It’s a great option, but the time required to learn how to use it doesn’t justify the investment, considering the limited time we have to complete the project.
• Java (Spring) -> he initial setup is more involved compared to Node.js, leading to a slower development pace at the start. Additionally, applications tend to consume more memory and resources, and the code requires more time to write and maintain due to its structured and complex nature

Status: Approved ✅

Architectural Decision 02 - Architecure

Option under discussion: Use a services architecture.

✅ Pros:

• Independent Scalability: Each service can be scaled individually according to the load it receives
• Parallel Development: We can work on separate services simultaneously without interference
• Fault Tolerance: If a service fails, it doesn’t necessarily affect the entire application

❌ Cons:

• Testing Difficulty: End-to-end testing becomes more complex, as you need to simulate or run multiple services to validate full workflows.
• Management Complexity: Coordinating multiple services requires additional tools and expertise.

🔄 Alternatives:

• Monolithic Architecture: The whole application is built and deployed as a single unit but as the app grows, it becomes difficult to maintain and scale.
• Modular Monolith: A single application structured into well-organized internal modules, but it still deploys as one piece,so a failure in one part can affect the entire system.

Status: Approved ✅

Architectural Decision 03 - Deployment

Option under discussion: Use of Docker.

✅ Pros:

• Portability: Docker containers can run in any environment that supports Docker, ensuring consistency across development, testing, and production.
• Isolation: provides strong isolation of processes, allowing applications to run independently without interfering with each other.
• Easy deployment: simplifies the deployment process and manages dependencies, as applications are packaged with everything needed to run.

❌ Cons:

• Resource overhead: Although containers are lightweight, they can consume additional resources depending on the number of containers and the complexity of the application.
• Security: Docker provides isolation for applications, but security risks remain, especially if containers are misconfigured or images have vulnerabilities.

🔄 Alternatives:

• Podman: Podman is a container management tool that aims to provide a similar experience to Docker but operates without a central daemon. This can be an advantage for certain use cases, but it also means that Podman may lack some features or tools that are widely available in Docker’s ecosystem, requiring more manual configuration

Status: Approved ✅

Architectural Decision 04 - DataBase

Option under discussion: Use of MongoDB.

✅ Pros:

• Scalability: MongoDB is highly scalable, allowing it to handle large volumes of data and traffic efficiently.
• Flexible Schema: MongoDB uses a flexible schema (NoSQL), meaning documents can have different structures, allowing the database to quickly adapt to changes in application requirements
• High performance: MongoDB provides high performance in read and write operations, making it ideal for applications that require fast data processing.

❌ Cons:

• Lack of complex relationships: While MongoDB can handle simple relationships between documents, it lacks the advanced relational capabilities offered
  by SQL databases.
• Resource-intensive: MongoDB can consume more memory and resources compared to relational databases due to its NoSQL nature and advanced indexing.

🔄 Alternatives:

• MySQL/PostgreSQL (SQL): While relational databases like MySQL and PostgreSQL are great for handling complex relationships and ensuring ACID compliance, they lack the flexibility and scalability that MongoDB offers.
• Cassandra: Apache Cassandra is designed for high write volumes and horizontal scalability, but it is not ideal for applications requiring complex queries or joins, as it lacks some of the query capabilities that MongoDB provides

Status: Approved ✅

Architectural Decision 05 - User Interface

Option under discussion: Use of ReactJS.

✅ Pros :

• Component-based architecture: ReactJS follows a component-based architecture, making it easier to build reusable UI components, promoting maintainability and scalability in large applications.
• Fast rendering with Virtual DOM: React uses a virtual DOM that optimizes rendering performance by minimizing updates to the actual DOM, improving user experience and reducing load times.
• Easy integration: React can be easily integrated with other libraries or frameworks.
• Large ecosystem and community support: React has a vast ecosystem of libraries, tools, and a large developer community, ensuring continuous support and resources for development.

❌ Cons:

• JSX syntax: React uses JSX, which combines HTML and JavaScript. This can be confusing for developers who are not familiar with it.
• Learning curve: While React's core concepts are relatively simple, mastering the full ecosystem (e.g., state management with Redux, routing with React Router) can be challenging for beginners.

🔄 Alternatives:

• Angular: Angular is a full-fledged framework that provides everything needed to build a large-scale application, but its steeper learning curve and opinionated approach can limit flexibility and make it harder for new developers to get started quickly.
• Svelte: Svelte compiles components into optimized vanilla JavaScript at build time, offering faster performance than React. However, its smaller ecosystem and community mean there are fewer third-party resources and libraries available.

Status: Approved ✅

Architectural Decision 06 - Backend

Option under discussion: Use of ExpressJS.

✅ Pros:

• Minimalistic and lightweight: ExpressJS is a minimal framework that offers just the essential features, allowing developers to add only the components they need for their application. This leads to fast development and flexibility.
• Easy to learn and use: ExpressJS has a simple API and is easy to learn.
• Great middleware support: Express has a rich ecosystem of middleware, enabling easy integration for routing, authentication, logging, error handling, and more.

❌ Cons:

• Scalability challenges: Express can become harder to manage as the application grows in size and complexity, especially if not structured properly.
• No strict structure: Express provides minimal guidance on how to structure an application, which can lead to inconsistent codebases.
• Callback hell and asynchronous handling: While Node.js's asynchronous nature provides performance benefits, it can lead to callback hell and hard-to-manage code.

🔄 Alternatives:

*Koa.js: Koa is more modern and uses async/await for simpler asynchronous code, but it lacks the built-in features and utilities that Express provides.

• NestJS: NestJS is built on top of Express and provides a more opinionated and structured framework, including support for TypeScript. While this is great for large, complex applications, it can be too heavy-handed for smaller projects, leading to unnecessary complexity and setup time.

Status: Approved ✅

Architectural Decision 07 - LLM Model

Option under discussion: Use Gemini as LLM model.

✅ Pros:

• Fast Response Generation: Gemini can generate clues in seconds, speeding up content delivery without delays, enhancing user experience.
• High Accuracy in Suggestions: With its advanced natural language processing, Gemini provides highly accurate and relevant clues tailored to what the user needs.

❌ Cons:

• Accuracy of Information: Like other AI models, Gemini can generate incorrect answers, in our case the clues.
• Dependency on Google Ecosystem: Integration with Google tools can create dependency on their ecosystem.

🔄 Alternatives:

• Empathy: We decided not to use it because it gave as a lot of problems.

Status: Approved ✅