Storing Data

The Finsemble Storage Client interfaces with the Storage Service to provide a central location for persistent storage and retrieval of application data across multiple component windows and services.

The Storage Client delivers one form of cross-original resource sharing (CORS), specifically cross-origin storage. If you don't care about cross-origin storage (or the other storage features the Storage Client provides), you have the option to bypass the Storage Client and directly access HTML5's localStorage from your component window. However, by using our Storage Client, different data stores can be transparently used, multiple users can be supported, and future storage enhancements can be inherited (e.g., storage backup, migration, permissions).

Finsemble supports only one data model: a key-value store. However, there's nothing preventing you from attaching your own virtual store that bridges to another database model.

Below is the high-level storage architecture.

Storage Architecture

Currently Finsemble supports only one data store in production: HTML5's localStorage. However, a prototype data store built on Redis is available on request. Also, as mentioned above, a virtual data store can be built to bridge the internal key-value data model to any external database, such as Oracle's relational database or MongoDB.

Using the Storage Client API

The Storage Client API supports simple key-value storage. It has three distinct Finsemble enhancements:

  1. All storage is by username, which is specified by the Authentication Service invoking the StorageClient.setUser method during startup—given the username is always set automatically, application developers never need to do it. If authentication is disabled, the underlying Authentication Service still sets the username to "defaultUser." This implies that changing the username (i.e., logging on through the Authentication Service with a different username) will change the storage being accessed. A new username always starts with empty storage.
  2. All storage is also partitioned by topic, which is kin to a namespace to prevent key conflicts. All of Finsemble's core storage uses "finsemble" as the topic. Application developers can use any topic they choose, which might be a application name or a company name.
  3. Storage's underlying data store can be selected by topic using the StorageClient.setStore method. This allows a specific component's storage to be redirected to it's own data store (e.g., Redis, Data Bridge) independent from Finsemble's default data store.


The Storage Service can utilize “topics,” allowing developers to determine where their data is saved. This allows developers to save some data locally and other data to the network.

Finsemble uses three storage topics.

  • "Finsemble.workspace" is storage for the Workspace and is only accessed when workspaces are initialized or explicitly saved by the user.
  • "Finsemble.workspace.cache" is temporary storage for high-frequency updates (e.g., window moves, resizes, opens, closes). Typically this should be assigned to “LocalStorageAdaptor”.
  • “Finsemble” is general topic than contains everything outside of the Workspace. This has low frequency usage—very little falls under this topic currently.

You can (and should) define your own topics for storage. The topics you define can be mapped to any adaptor by inserting a corresponding entry under topicToDataStoreAdaptors: the property name (e.g. “Finsemble.workspace”) must be the topic and the property value (e.g. “LocalStorageAdaptor”) must be the adaptor.

Further reading

Advanced information about storing data can be found in the Storage Client documentation.

Read the Router tutorial to better understand how Finsemble sends and receives messages.

For additional information about how we store and share data, check out the Distributed Store.

For an example of data sharing between windows, proceed on to Drag and Drop Sharing.