Files
SYSTEM/docs/prd/technical-assumptions.md
2025-09-01 01:52:06 +03:00

2.3 KiB

4. Technical Assumptions

Repository Structure: Monorepo

The project will be developed within a single monorepo. This approach is chosen to simplify dependency management and ensure consistency between the frontend and backend components, especially since they will be tightly coupled and share types and logic.

Service Architecture

For the MVP, the backend will be a Monolith. This simplifies development, deployment, and hosting on a single Raspberry Pi. The architecture should be internally modular to allow for potential future extraction of services if needed, but the initial deployment will be a single service.

Testing Requirements

The project requires a robust testing strategy focused on data integrity. The minimum requirement is Unit + Integration Testing.

  • Unit Tests: Every individual function, especially cryptographic helpers and business logic calculators, must be covered by unit tests.
  • Integration Tests: These are critical to validate the end-to-end flow of transactions within "The Main Ledger". Tests must cover scenarios like: creating a "Cell", adding participants, confirming payments, and verifying that the final calculated state is correct.

Additional Technical Assumptions and Requests

  • Hosting: The entire application must be deployable and performant on a Raspberry Pi (Model 4 or newer). Deployment will be managed via Docker Compose.
  • Core Tech Stack: The primary technology stack is Nuxt 4 (Vue 3) for the frontend and PostgreSQL for the database. The backend can be implemented using Nuxt 4's server capabilities.
  • Styling: Styling will be implemented using SCSS and Tailwind CSS. A component framework (e.g., Nuxt UI, PrimeVue) is anticipated and will be chosen during the architecture phase.
  • Cryptography: Transaction signing will use the Ed25519 algorithm or a similar lightweight, secure standard. The client is responsible for signing transactions unless the user opts into the server-side "Vault".
  • Internationalization (i18n): The frontend application must be architected with i18n support from the ground up, even though the MVP will only ship with a single language pack.
  • API Design: The API should be designed internally. No requirement for a public-facing REST/GraphQL API in the MVP, as the frontend and backend are tightly coupled.