Skip to content

Latest commit

 

History

History
69 lines (53 loc) · 4.31 KB

adr007-local-storage-for-offline-capabilities.md

File metadata and controls

69 lines (53 loc) · 4.31 KB
Raw

ADR007: Local Storage for Offline Capabilities

Status: accepted

Context

ADR002 introduces the concept of offline storage into the architecture. The offline storage is a local, per device cache for the whiteboard CRDT documents described in ADR004. There are several reasons for which such a storage is desired:

  • Protect from data loss: Our widget runs inside an iframe that a user can decide to close at any time. There is no feedback to the widget that it is closed, therefore we are unable to store the latest state to the room before closing. We are notified via events, however are unable to run asynchronous operations as part of these events. Therefore we want to store changes regularly locally and restore them the next time the whiteboard widget is opened.
  • Offline editing: In case of connectivity issues the user wants to be able to edit locally, without loosing data if writing snapshots into the Matrix room fails (see ADR005). The user should be able to sync his changes once connectivity is available again.
  • Improved performance: As a whiteboard can consist of multiple snapshots and each of them out of multiple chunks, it might take some time till all required data is loaded. Lazy loading of events, end-to-end encryption, or invalid snapshots (e.g. snapshots that are still being written) have an impact on the load performance. The list of whiteboards will require that a lot of whiteboards are loaded to display thumbnails. Therefore caching the documents locally will improve the load time of the documents. Even though locally stored documents might not be up to date, they can be enhanced with the latest state from the Matrix room once it arrives.

The Web platform provides multiple storage APIs:

  • localStorage: Most commonly available API, providing a simple key-value storage.
  • IndexedDB: A simple key-value based database, with support for indices.
  • WebSQL: A now deprecated API with the goal to provide a SQL compatible database.
  • CacheStorage: A API for controlling the browser cache in combination with service workers.

Decision

We will use an offline storage to improve performance, protect from data loss and handle connectivity issues. We prefer storing data in IndexedDB as it has support for binary data (like Uint8Array), however due to the higher availability of localStorage we should support both. As localStorage and IndexedDB don't automatically evict old unused data, we will use a least recently used (LRU) storage policy with a fixed size. This avoids that we run into the size quota of the storage.

Consequences

To avoid dealing with the complexity of IndexedDB and the complexity to handle both localStorage and IndexedDB, we can use a common wrapper like LocalForage.