Evaluating Storage Strategies for Unisala's Draft Management

This thread revolves around evaluating the technicality of current data storgae methods used in Unisala's platform, specially how drafts are managed. What kind of data structures are used like key value pair vs trees & graph. We will also evaluate & explore some client side storage like local storage vs indexDb. This thread

Context:

As the user base is growing in terms of user base and feature complexity, the current methods of storing drafts will bottleneck. We are exploring a migration to indexDb and possibly integrating more complex data structures like trees and graphs. to efficiently manage drafts that have different versions and revisions.

Current Implementation Using LocalStorage

Pros:

1. Simplicity: Easy to use and implement
2. Speed: Data is stored locally, fast read & write operations without network latency.
3. No dependency: No exposure as we are using built it storage.

Cons:

1. Scalability Issues: Managing localStorage can become problematic.
2. Storage limit: Typically limited to 5mb per domain.
3. Lack of structure: Data must be stored in key-value pairs, requiring serialisation and deserialisation of complex objects.

Possibility of why IndexedDB?

Pros:

1. Better suited for handling larger datasets, complex data structures.
2. Rich query abilities: Supports transactions, indexes & the ability to store & retrieve objects based on querying object properties.
3. Increased Storage Capacity: Provides significantly more storage space than localStorage.
4. Asynchronous Api: Doesn't block the UI thread, improving the user experience in complex applications.

Cons:

1. Complexity: More complex api can increase the development time & learning curve.
2. Browswer support variablity: While widely supported, there are differences in how browsers handle indexedDB which might affect performance & behaviour across platforms.
3. Potential Overhead: More overhead in terms of managing database connections & transaction compared to straightforward key-value storage.

Current Data Structures

Key-Value Pair Object Store:

Pros:

1. Simplicity: Easy to implement & understand. Suitable for small scale applications where drafts do not have complex relationships or hierarchical dependencies.
2. Speed: Quick access to data using keys, making it efficient for scenarios where the primary operation is retrieving a full draft by its identifier.

Cons:

1. Limited Scalability: As the number of draft grows
2. draft becomes complex like multiple versions or collaboration.
3. This approach might become inefficient.
4. Flat Structure: Does not inherently support hierarchical data, which may be necessary if drafts are parts of larger projects or require categorisation.

Alternative: IndexedDB

Given that we are considering client side solutions, we might want to maintain the applications performance as it scales, indexDB offers several advantage.

Pros:

1. Structured storage: Allows us to store object directly & support indexing which can make quries faster & more efficient.
2. Scalability: More suitable for larger amount of data & complex data types then localstorage, without 5mb limit.
3. Asynchronous Operations
4. Rich Query Capabilities.

Cons:

1. Complexity: More complex to implement & requires a good understanding of database transactions & asynchronous programming.

Tree or Graph Structures:

If your drafts have more complex relationships or hierarchical structures (such as revision, versions) using tree or graph might be beneficial:

Pros:

1. Hierarchical Organization: Natural fit for managing data or items with multiple dependencies.
2. Efficient Data Retrieval: Allows for efficient retrieval or hierarchical data which can be optimised further with appropriate indexing strategies.

Cons:

1. Implementation: Requires custom implementation for efficient management.
2. Complexity in Operations: More complex operations required to traverse or update nodes compared to flat key-value pairs.

Conclusion:

For simplicity & moderate scale, since our application does not expect extremely complex data relationships or massive scale, sticking with key value pair approach using indexedDB might be the best balance between complexity & performance. It offers advantage of using localStorage in terms of capacity and functionality without the overhead of managing complex data structures like tree or graphs.

This technical discussion is crucial for strategically planning the future architecture of Unisala's platform. It affects everything from user experience i.e speed and responsiveness to the feasibility of new features like collaborative editing. Decisions made here will shape how effectively the platform can serve its users as it scales.

#Unisala #ClientSideStorage #IndexedDB #LocalStorage #DataStructures #WebDevelopment #DatabaseManagement #PerformanceOptimization #TechDiscussion #StorageSolutions