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 a CORS solution, specifically cross-origin storage. If a developer doesn't care about cross-origin storage (or the other storage features the StorageClient provides) they have the option to bypass the Storage Client, instead directly accessing HTML5's localStorage from their component window. However, by using our Storage Client different data stores can be transparented used (more on this below), multiple users are supported, plus future storage enhancements can be inherited (e.g. storage backup, migration, permissions).

Finsemble supports only one data model, a key-value model. However, there's nothing preventing a customer from attaching their own virtual store that bridges to another database model. (Our support team would be happy to help you get started on if you want to build a custom data store or bridge.)

Below is the high-level storage architecture. Note the datastore used within the Storage Service can be changed without any effect on the Storage Client or the applications that use it.

Storage Architecture

Currently Finsemble supports only one data store in production, HTML5's localStorage, but a prototype datastore 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 DB or Mongo DB.

Using the Storage Client API

The Storage Client API supports simple key-value storage, however is has three distinct Finsemble enhancements:

  1. All storage is by username, which is specified by the Authentication Service invoking 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 Authentication 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 StorageClient.setStore method. This allows a specific component's storage to by redirected to it's own data store (e.g. Redis, Data Bridge) independent from Finsemble's default data store.