Architecture Decision Record
11. Continuous Integration and Continuous Delivery
Date: 2024-11-25
Status
Accepted
Context
We need to setup CI/CD pipeline to automate workflows for faster releases as defined in the 2019 Accelerate State of DevOps (DORA).
Decision
We will rely on Github DevOps toolkit for CI/CD pipeline.
Consequences
We can use Github Action to enhance our workflow.
12. Infrastructure as Code
Date: 2024-11-25
Status
Accepted
Context
We need to setup IaC pipeline to automate infrastructure creation as describe in 2016 Thoughworks blog.
Decision
We will use Bicep to deploy Azure resources.
Consequences
We need to define an Bicep file for project relying on Azure resources.
13. Frontend framework
Date: 2024-11-25
Status
Accepted
Context
We want to develop our Frontend with a Mobile first approach.
Decision
We will use Ionic as a mobile SDK for the Web. Ionic is an open source UI toolkit for building mobile apps using web technologies (HTML, CSS, and JavaScript) with integrations for popular frameworks like Angular, React, and Vue.
Consequences
We will generate App for Web and Mobile (iOS and Android) from a unic code base.
14. Identity and Access Management
Date: 2024-11-25
Status
Accepted
Context
We need to ensure that only identified and authorized user can access data and resources.
Decision
We will use Auth0 to authenticate users and Google Identity Provider to grant access to Drive API.
Consequences
We need to integrate AuthO React SDK to our Frontend, setup Authorization Code Flow with PKCE and define Google as Identity Provider.
15. Backend framework
Date: 2024-11-25
Status
Accepted
Context
We need to enable and secure access to backend and external API.
Decision
We will use Express to develop our backend and secure acess to Google Drive API.
Consequences
To secure Google Drive API access, we will implement call on backend side.
16. Local Docker
Date: 2024-11-25
Status
Accepted
Context
We need a local solution to develop Docker image.
Decision
We will use Podman for security concerns as explain in Alex Gamela post.
Consequences
Podman enable us to deploy locally NodeJS server image.
17. Distributed application
Date: 2024-11-25
Status
Accepted
Context
We need to define distributed application in an event driven architecture.
Decision
We will use Dapr to support communication, state and workflow with best pactices for security, resiliency and observability.
Consequences
We will use Dapr CLI and integrate dapr sidecars to our local dev environment.
18. Add publish and subscribe components
Date: 2024-12-09
Status
Superceded by 20. Add publish and subscribe components
Context
We want to implement asynchronous component to process Markdown file.
Decision
As we rely on Dapr, we will use Pub/Sub component with Redis to implement asynchronous process as describe in Dapr documentation.
Consequences
We will implement a Python App based on Flask as a Dapr Subscriber to process our Markdown file.
19. Process Service
Date: 2024-12-14
Status
Accepted
Context
To process Markdown file, we want to implement a simple and fast Python microservice.
Decision
As we rely on a microservice Architecture, we will use a simple, robust and standard-based framework to improve Python API implementation.
Consequences
We will integrate FastAPI, a modern, fast (high-performance), web framework for building APIs with Python based on standard Python type hints.
20. Add publish and subscribe components
Date: 2024-12-16
Status
Accepted
Supercedes 18. Add publish and subscribe components
Context
We want to implement asynchronous component to process Markdown file.
Decision
As we rely on Dapr, we will use Pub/Sub component with Redis to implement asynchronous process as describe in Dapr documentation.
Consequences
We will implement a Python App based on FastAPI as a Dapr Subscriber to process our Markdown file.
We will rely on Azure Service Bus as a message broker with Queue pattern for one-to-one communication.