Using Fluid for temporary storage

Some developers may wish to use the Fluid container for temporary storage only, choosing to use another data store for the long-term storage of the data after the collaboration period has passed; or choosing to not store the data at all, as it may have no usefulness beyond the collaboration period.

In this scenario, we assume the data in the primary data store will be temporarily copied to a Fluid container so that it can participate in a real-time collaboration experience for some period of time, and that it will not be edited in the original location while it’s in the Fluid container. All the business logic described here is assumed to be executed on the client in the context of the current user.

Getting data into the container

The developer is responsible for connecting to the external data store from their client-side web application, finding the appropriate data, and marshalling the data into a new Fluid container. We recommend creating the container in a detached state, inserting the external data into new shared objects, and then attaching the container. This avoids the situation where another user opens the container and the seed data is not yet present.

Locking the source data

Keeping data in sync between a Fluid container and an external data store is beyond the scope of this discussion. If the contents of the Fluid container are going to be written back to the original data store, the developer should take some precaution to ensure that users aren’t writing to the original data store while the data is also being edited in the Fluid container.

Data permissions

The user that initiates the transfer of the data into the Fluid container would need to have permissions to read the source data and set whatever locking mechanism is used to keep other users from editing the source data while it resides in the Fluid container. The other users in the collaboration experience do not need to have access to the original data store. This enables developers to delegate editing of specific data elements. Because the data transfer is all managed on the client, only users with access to the original data store should have the option to save changes back to the source. The developer is responsible for managing the user experience of the “save” action, including which clients have the option to save updates back to the original data store.

Container/session state and writing data back to the external data source

One of the more challenging aspects of this scenario is knowing the current state of the data and the Fluid container, and conveying that state to users. In the course of a Fluid session, operations are generated by all clients that represent changes in the current state of the data. Fluid uses an “eventually consistent” model, which means that at any given point in time, any given client might not have the full state of the container represented locally.

When the data saving logic runs client-side, it makes sense to have this logic run in the context of a single user, operating on the local data that this user is seeing. If the other clients in the session haven’t agreed to stop sending operations, the data is still subject to change after the “saving client” writes the data to the source of truth data store.

Fluid Framework does not contain built-in functionality to limit a client’s ability to edit a container. However, developers can add this functionality to their containers and manage the editable/non-editable state within the container themselves. A consensus-based distributed data structure (DDS) can be used to coordinate between clients. When saving needs to occur, one client can change the container to a non-editable state, and once all clients confirm, the save operation can continue.

Developers are responsible for managing the writing of data back to the original data store, including the frequency of writes, unlocking the original data store, managing the situation where users don’t trigger the write action from the application as expected, etc.