(TK-003): Create the Webank-UserApp Architecture

[Arielpetit]

Description:

The objective of this task is to ensure the Webank-UserApp architecture is clearly documented to guide the development process and address key technical decisions, such as:

• How the UserApp will communicate with the backend.
• What structure is followed for frontend components.
• How security is handled during user registration and OTP verification.
• Future scalability considerations.

Requirements:

• Develop a high-level architecture document and diagram.
• Define the structure and flow between frontend components.
• Outline how the UserApp will communicate with backend API endpoints.
• Address security considerations, such as data encryption and secure communication between the frontend and backend.
• Ensure scalability for future feature additions (e.g., transaction history, account management).

Acceptance Criteria:

• A detailed architecture document covering key frontend components (Registration, OTP Verification, Dashboard).
• A component/block diagram showing the interaction between frontend components and backend APIs.
• Clear explanation of how state management will be handled (e.g., Redux or React state).
• Security considerations are addressed, including the use of HTTPS and token-based authentication (if applicable).
• Future enhancement possibilities are considered in the architecture.

Estimate: 5

[francis-pouatcha]

Description from https://github.com/adorsys/eudiw-app/issues/20

The objective of this task is to document the decision taken on the architecture of the project. we need to understand why:

there is a fe-be secure layer in the app why we're building an event bus for communication the reason for abstraction of the fe components from fe-be components, how to define interfaces for communication between fe components and fe-be components

[francis-pouatcha]

1. FE-BE Secure Layer: The decision to include a secure layer between the front-end (FE) and back-end (BE) is primarily driven by the need to protect data integrity and privacy. In a mobile app, sensitive information such as user credentials, personal data, and transaction details are often exchanged between the client and server. The secure layer uses encryption to ensure that this data cannot be intercepted or tampered with during transmission. This is crucial for maintaining user trust and for compliance with data protection regulations.

2. Event Bus for Communication: The use of an event bus is a common pattern in modern app development, particularly in apps that follow a microservices architecture. The event bus allows different components of the app to publish and subscribe to events. This means that a component can react to events that it is interested in, without needing to know which other component produced the event. This decoupling of components leads to a codebase that is easier to maintain and evolve over time.

3. Abstraction of FE Components from FE-BE Components: The decision to abstract the FE components from the FE-BE components is a reflection of the Single Responsibility Principle (SRP). By ensuring that the FE components are only concerned with presentation logic, and the BE components with business logic, we increase the maintainability and testability of the code. This separation of concerns also makes it easier to work on the FE and BE independently, which can be a big advantage in a team development environment.

4. Defining Interfaces for Communication between FE and BE: Defining clear interfaces for communication between the FE and BE is crucial for the robustness of the app. These interfaces, often defined in an API (Application Programming Interface), ensure that both the FE and BE agree on the format of the data to be exchanged. This reduces the likelihood of errors and makes the system easier to debug.

[francis-pouatcha]

Architecture Decision Document

Objective

The objective of this document is to document the architectural decisions made for the project, with a focus on security and communication between components.

1. Frontend-Backend Secure Layer

• Decision: Incorporate a secure layer between the frontend (FE) and backend (BE) components.
• Reasoning:
  • Security Concerns: Ensure encrypted communication to prevent security threats such as malicious code injection, cross-site scripting (XSS), and cross-site request forgery (CSRF).
  • Data Protection: Safeguard sensitive data transmission by validating and sanitizing user input, implementing Content Security Policy (CSP) and Subresource Integrity (SRI), and using secure cookies and local storage.
  • Compliance Requirements: Meet encryption standards for regulatory compliance.

2. Event Bus for Communication

• Decision: Implement an event bus for communication.
• Reasoning:
  • Loose Coupling: Promote flexibility and scalability with event-driven architecture.
  • Asynchronous Communication: Facilitate non-blocking communication between components.
  • Scalability: Enhance scalability by decoupling components through events.

3. Abstraction of FE Components from FE-BE Components

• Decision: Abstract frontend (FE) components from frontend-backend (FE-BE) components.
• Reasoning:
  • Separation of Concerns: Promote maintainability by separating FE and FE-BE logic.
  • Reusability: Enable reuse of FE components across different parts of the application.
  • Modularity: Facilitate independent development and maintenance of FE and FE-BE components.

4. Defining Interfaces for Communication between FE Components and FE-BE Components

• Decision: Define clear interfaces for communication between FE components and FE-BE components.
• Reasoning:
  • Contract Definition: Establish a standardized contract for consistent interaction.
  • Encapsulation: Hide internal implementation details, promoting encapsulation.
  • Interoperability: Ensure interoperability between different components and technologies.

5. Back-end Security

• Decision: Implement robust security measures in the back-end.
• Reasoning:
  • Unauthorized Access: Protect against unauthorized access, data breaches, and denial-of-service (DoS) attacks by implementing authentication and authorization mechanisms.
  • Secure Protocols: Use secure protocols and standards like OAuth, OpenID Connect, or JSON Web Tokens (JWT), and employ multi-factor authentication (MFA) and password hashing and salting.
  • Data Encryption: Encrypt data stored or transmitted by the back-end, and use SSL/TLS certificates for secure connections.

6. Database Security

• Decision: Implement stringent security measures for the database.
• Reasoning:
  • SQL Injection: Prevent SQL injection by using parameterized queries or prepared statements.
  • Data Leakage: Use Role-Based Access Control (RBAC) and encryption to restrict and protect the data accessed by database users and clients.
  • Secure Configuration: Maintain secure configuration and patching to ensure the security and performance of the database.

Conclusion

Documenting these architectural decisions provides insight into the rationale behind the design choices, guiding future development efforts and ensuring alignment with project goals and requirements. This includes a strong emphasis on security at all levels of the application, from the front-end to the back-end and the database, as well as efficient communication between components.