From 231629edd60124e09c5b844eca03822f759f1b24 Mon Sep 17 00:00:00 2001 From: Milan Milanovic Date: Tue, 18 Jun 2024 17:41:15 +0200 Subject: [PATCH] Add adr2 --- build/docs/index.html | 101 +++++++++++++++++- .../asciidoc/sections/09_decision_log.adoc | 3 +- .../sections/adrs/0001-login-decision.adoc | 19 +++- .../adrs/0002-technology-selection.adoc | 29 +++++ 4 files changed, 141 insertions(+), 11 deletions(-) create mode 100644 src/docs/asciidoc/sections/adrs/0002-technology-selection.adoc diff --git a/build/docs/index.html b/build/docs/index.html index 3185d41..1ee0eb3 100644 --- a/build/docs/index.html +++ b/build/docs/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.

    +
    • +
diff --git a/src/docs/asciidoc/sections/09_decision_log.adoc b/src/docs/asciidoc/sections/09_decision_log.adoc index 09d3a9f..91de3f4 100644 --- a/src/docs/asciidoc/sections/09_decision_log.adoc +++ b/src/docs/asciidoc/sections/09_decision_log.adoc @@ -1,4 +1,5 @@ == 9. Architecture Decisions Records -include::adrs/0001-login-decision.adoc[] \ No newline at end of file +include::adrs/0001-login-decision.adoc[] +include::adrs/0002-technology-selection.adoc[] \ No newline at end of file diff --git a/src/docs/asciidoc/sections/adrs/0001-login-decision.adoc b/src/docs/asciidoc/sections/adrs/0001-login-decision.adoc index 524c69c..4f55ff1 100644 --- a/src/docs/asciidoc/sections/adrs/0001-login-decision.adoc +++ b/src/docs/asciidoc/sections/adrs/0001-login-decision.adoc @@ -1,15 +1,24 @@ -=== 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. ==== 9.1.2. Considered Options -* Option 1 -* Option 2 +* **Option 1**: Traditional Username and Password Authentication +* **Option 2**: OAuth 2.0 with Social Login +* **Option 3**: Single Sign-On (SSO) with SAML ==== 9.1.3. Decision Outcome -We selected option 1, because X. \ No newline at end of file +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. \ No newline at end of file diff --git a/src/docs/asciidoc/sections/adrs/0002-technology-selection.adoc b/src/docs/asciidoc/sections/adrs/0002-technology-selection.adoc new file mode 100644 index 0000000..c89d99d --- /dev/null +++ b/src/docs/asciidoc/sections/adrs/0002-technology-selection.adoc @@ -0,0 +1,29 @@ + +=== 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. \ No newline at end of file