diff --git a/index.html b/index.html index 946c177..77e5653 100644 --- a/index.html +++ b/index.html @@ -565,11 +565,11 @@

8.3. Logging

9. Architecture Decisions Records

-

9.1. Login decision

+

9.1. ADR-001: Login decision

9.1.1. Context and Problem Statement

-

We want to enable user login.

+

We need to choose an authentication method for user login in our new application. The method should ensure security, ease of use, and scalability while providing a seamless user experience.

@@ -577,10 +577,13 @@

9.1.2. Considered Options

  • -

    Option 1

    +

    Option 1: Traditional Username and Password Authentication

  • -

    Option 2

    +

    Option 2: OAuth 2.0 with Social Login

    +
  • +
  • +

    Option 3: Single Sign-On (SSO) with SAML

@@ -588,7 +591,95 @@

9.1.2. Considered Options

9.1.3. Decision Outcome

-

We selected option 1, because X.

+

We have decided to implement OAuth 2.0 with Social Login.

+
+
+

Rationale:

+
+
+
    +
  • +

    Security: OAuth 2.0 is a widely adopted and secure protocol for authorization.

    +
  • +
  • +

    User Convenience: Social login allows users to log in with existing accounts (e.g., Google, Facebook), reducing friction and improving user experience.

    +
  • +
  • +

    Scalability: OAuth 2.0 can handle a large number of users and integrates well with third-party identity providers.

    +
  • +
  • +

    Reduced Maintenance: Leveraging third-party identity providers reduces the burden of managing user credentials and security.

    +
  • +
  • +

    Adoption and Integration: Many users prefer using their social accounts for quick access, and many modern applications support OAuth 2.0, making it easier to integrate with other services.

    +
  • +
+
+
+
+
+

9.2. ADR-002: Technology selection

+
+

9.2.1. Context and Problem Statement

+
+

We need to choose a technology stack for developing our new web application. The application requires a robust backend, an interactive frontend, and seamless integration with third-party services.

+
+
+
+

9.2.2. Considered Options

+
+
    +
  • +

    Option 1: Node.js with Express, React.js, PostgreSQL, AWS

    +
  • +
  • +

    Option 2: Python with Django, Angular, MySQL, Google Cloud Platform

    +
  • +
  • +

    Option 3: Ruby on Rails, Vue.js, MongoDB, Microsoft Azure

    +
  • +
+
+
+
+

9.2.3. Decision Outcome

+
+

We have decided to use the following technology stack:

+
+
+
    +
  • +

    Backend: Node.js with Express framework

    +
  • +
  • +

    Frontend: React.js

    +
  • +
  • +

    Database: PostgreSQL

    +
  • +
  • +

    Hosting: AWS (using services such as EC2, S3, and RDS)

    +
  • +
+
+
+

Rationale:

+
+
+
    +
  • +

    Node.js and Express: Chosen for their performance, scalability, and large ecosystem.

    +
  • +
  • +

    React.js: Selected for its component-based architecture, ease of use, and strong community support.

    +
  • +
  • +

    PostgreSQL: Preferred for its robustness, ACID compliance, and advanced querying capabilities.

    +
  • +
  • +

    AWS: Offers a reliable and scalable cloud infrastructure with a range of services that meet our needs.

    +
  • +
@@ -700,7 +791,7 @@

12. Glossary