Finsemble: Storing Data

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.

Further reading

Read the Finsemble 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, check out Sharing Data.