🛠️ [TASK] : Persist data in the frontend

[minikin]

Summary

We need a robust, cross-platform local storage solution for our Flutter application. While our immediate use case involves persisting proposals and comments, the primary focus is on determining an architecture that is both scalable and adaptable to various data types in the future. This solution must function smoothly on web, iOS, Android, macOS, Linux, and Windows.

Description

Currently, the application only retrieves data from the backend and does not store anything locally. To improve user experience (especially when offline) and reduce server load, we want to establish an architectural approach for a local storage mechanism. Please note: this task is for the architecture team—no implementation is required at this stage.

Core Objectives

1. Evaluate Cross-Platform Storage Options
   • Investigate libraries such as Hive, Sembast, ObjectBox, Floor, or SQLite to confirm compatibility with web, iOS, Android, macOS, Linux, and Windows.
2. Define Architectural Patterns
   • Propose how local storage will integrate with existing architecture.
   • Consider service/repository patterns, dependency injection, and any necessary interfaces for maintainability.
3. Outline Sync & Offline Strategy
   • Sketch how data should be cached, synchronized, and conflict-resolved (at a high level).
4. Assess Performance & Scalability
   • Identify potential limitations for large datasets.
   • Recommend optimizations or best practices (e.g., indexing, lazy loading).
5. Address Security Concerns
   • Determine if encryption or secure storage is needed based on data sensitivity.
   • Evaluate potential solutions for data integrity (transactions, error handling, fallback procedures).

Key Requirements

• No Implementation: Provide architectural recommendations and a high-level design only.
• Future-Friendly: The proposed architecture should be flexible enough to handle additional data models in future releases.
• Minimal Platform Constraints: The solution must work seamlessly across the specified platforms (web, iOS, Android, macOS, Linux, Windows).

Deliverables

1. Architecture Proposal
   • A document or diagram detailing the recommended local storage solution and how it fits into our existing Flutter application.
   • Rationale for choosing (or rejecting) each technology.
2. Sync Strategy Outline
   • Description of how to handle offline writes and subsequent sync with the backend.
   • Basic conflict-resolution considerations.
3. Security & Performance Recommendations
   • Any high-level guidance on data encryption, protection, or performance tuning.
4. Roadmap for Implementation
   • Proposed phases or steps for how the development team can implement this solution in the future.

Acceptance Criteria

• An architectural proposal is delivered, including recommended local storage library/libraries.
• A high-level design or diagram shows how this storage layer will integrate with the existing Flutter app.
• A brief plan for syncing and offline functionality is provided, with notes on potential conflict resolution.
• Security, performance, and scalability considerations are addressed.
• Any outstanding concerns or trade-offs are clearly documented (e.g., why one solution might be favored over another).

Additional Notes

• Please keep the deliverables concise yet comprehensive enough to guide the eventual implementation.
• If multiple solutions are feasible, include a pros/cons comparison.
• We will schedule a follow-up session to discuss the final architecture and plan the next steps for development.

[LynxLynxx]

Worth considering Drift

[damian-molinski]

See my libs spike here, may be useful when you'll evaluate libs

[neil-iohk]

Scope Evaluation for Fund 14

During the evaluation process, all items outlined in the ticket were reviewed. However, the scope for Fund 14 has been defined with a narrower focus. The following outlines the features and requirements that are within scope for this phase:

In Scope for Fund 14

• Document Retrieval and Local Storage:

  • Enable the retrieval of documents from an API and store them locally to reduce the number of API requests, thereby improving frontend performance.
  • Implement a local storage mechanism to function as a cache for documents, distinct from traditional HTTP request caching in the browser which is not in scope.

• Draft Document Management:

  • Store draft documents in local storage until the user signs and submits the document, facilitating editing within the application.
  • Ensure documents are identifiable by both ID and version. which will correlate to UI iteration terminology.

• Metadata and Structured Storage:

  • Store documents in JSON format within local storage.
  • Support the storage of document metadata as returned by the index API.

• Assumptions:

  • The user is not on a shared device and the user is responsible for the management of sensitive data if the application is used on a shared device.

Out of Scope for Fund 14

• Device Synchronization:

  • Multi-device sync, conflict resolution, and peer-to-peer (P2P) synchronization.

• Multiple Storage Providers:

  • Support for alternative backends, cloud storage solutions, and distributed systems (IPFS etc.).

• Advanced Collaboration:

  • Real-time multi-user editing / Teams.
  • Differential synchronization and IPFS integration.
  • Conflict resolution mechanisms (e.g., CRDTs).

• Index Synchronization:

  • Remote or distributed index updates.

• Cache Management:

  • Automatic purging of outdated metadata and document versions.

• Encryption:

  • At this stage, draft documents will be stored in local storage unencrypted.

• User-Linked Sessions:

  • Session management linked to user authentication is currently out of scope.