Fluid Framework: Distributing Data & Scaling Solutions

Microsoft’s Fluid Framework is a collection of client libraries designed to synchronize distributive processes during collaborative application development. It provides:

• Client-centric application models w/persistent data sans custom server code.
• Distributed data structures w/recognizable programming patterns.
• Significantly low latency.

Fluid Framework provides developers with “distributed data structures” (DDSes) that automatically ensure that each client has access to the same state. By maintaining connections to services, while synchronizing clients, Fluid Framework enables development exclusive to the client experience. According to GitHub:

“These libraries allow multiple clients to create and operate on shared, synchronized distributed data structures using coding patterns similar to those used to work with local data.”

Distributed Data Structure (DDS) *

DDSes form the “foundation” of Fluid Framework. Similar to data structures commonly used for programming (i.e., strings, maps/dictionaries, sequences/lists), they may consist of text, images, and other binary data sets of any size.

DDSes remain in sync while each client operates on them as they would on local data. A Fluid solution data source can represent several data structures like:

• SharedMap - a distributed data structure that can be used to store key-value pairs. Though similar to JavaScript Map, its keys MUST be strings.
• SharedString - a specialized data structure that enables simultaneous text data editing, in real-time, by multiple clients. It contains metadata storage markers within the text.

* Developers can use the DDSes included with Fluid Framework or develop new ones.

Scaling Fluid Solutions

The experience on the client depends on the Fluid data store and the local device. When scaling solutions, the client’s handling and rendering of changes versus service distribution efficiency must be weighed. “Service scale” and, to a greater extent, “client scale” are the key variables in Fluid solution design; while inbound change management is particularly pertinent at high volume.

Strategically, determining DDS usability and structural types is paramount when scaling fluid solutions. Virtualization can be deployed to limit the scope of view updates, while throttling inbound changes can limit the number of required updates. Ultimately, developing the right solution strategy is contingent upon the nature of the scenario.