Frequently Asked Questions
The following are short, sometimes superficial, answers to some of the most commonly asked questions about the Fluid Framework.
What is the Fluid Framework?
The Fluid Framework is a collection of client libraries for building applications with distributed state. These libraries allow multiple clients to create and operate on shared, synchronized distributed data structures (DDSes) using coding patterns similar to those used to work with local data. The Fluid Framework manages connections to services and keeps all clients in sync so that developers can focus on the client experience.
The Fluid Framework was designed with performance and ease of development as top priorities.
Distributed Data Structures
What is a DDS?
DDS is short for distributed data structure. DDSes are the foundation of the Fluid Framework. They are designed such that the Fluid runtime is able to keep them in sync across clients while each client operates on the DDSes in largely the same way they would operate on local data. The data source for a Fluid solution can represent numerous DDSes.
There are many types of DDSes including a SharedMap that is a distributed version of a JavaScript Map, and a SharedString that is designed to enable real-time editing of text data by multiple clients simultaneously. Developers can use the DDSes included with the Fluid Framework or develop new ones.
Any practical limits on the types of data and size of a DDS will be specific to the implementation of that DDS. DDSes can contain text, images, and other binary data and can effectively be any size. However, managing scale on the client requires thought, just as it does when working with local data.
Where is the data stored?
There are two classes of data storage to discuss when answering this question: session storage and persistent storage.
Session storage is managed by the Fluid service and is, essentially, a central record of all the operations (ops) performed on the DDSes. This record is used by the Fluid clients to produce identical local instances of the DDSes. Session storage also includes ops that summarize all past operations to improve performance for clients that join sessions later and for efficiencies when saving to persistent storage.
Persistent storage is a record of ops (and summary ops) saved outside of the Fluid service. This could be a database, blob storage, or a file. Using persistent storage allows a Fluid solution to persist across sessions. For example, current Microsoft 365 Fluid experiences save ops in .fluid files in SharePoint and OneDrive. It is important to note that these files share many of the properties of a normal file such as permissions and a location in a file structure, but because these experiences rely on the Fluid service, downloading the files and working locally is not supported.
How is data synchronized?
In order to keep all clients in sync, they must be connected to a Fluid service. This service's core responsibility is sequencing all the incoming Fluid operations and then broadcasting them to all clients. Because the ops are ordered, and because each client is running the same code, the DDSes in each client eventually end up in an identical state.
Note, there isn't a centralized Fluid service for all Fluid experiences. But for each Fluid experience, there is only one Fluid service.
Fluid clients connect to the Fluid service using the WebSocket protocol. However, the Fluid runtime manages all of the connections so that Fluid client developers can focus on local experiences.
Scale
How many concurrent users does this support?
It depends. Because the Fluid service is extremely lightweight, even a simple implementation of the service can support 100s of concurrent users. A more sophisticated implementation can distribute the work and support 1000s. The experience on the client will vary depending on the Fluid data store and local device. When considering scale for Fluid solutions, consider how well the client can handle and render changes, not whether the service is able to distribute them efficiently.
Also, there is a significant difference in capacity depending on whether users are purely viewers vs. editors. Adding viewers scales far more than adding editors because each editor increases the volume of changes and viewers do not.
How do you design Fluid Framework solutions to scale?
When thinking about scale there are two key factors: service scale and client scale. The Fluid service is designed from the ground up to be extremely scalable. While there is the potential to refine the service to the point where it is staggeringly scalable, for most Fluid developers the larger concern will be client scale.
When tackling client scale, developers need to consider how they will manage inbound changes, especially when the volume of changes is high. The specific strategies developers should consider start when considering which DDS types to use and how the data is structured. From there developers can look at using virtualization to limit updates to parts of the view that are currently in scope. Another strategy could be to throttle inbound changes to limit the number of updates that are required. Of course, the right strategies will depend enormously on the specific scenario.
Fluid Technology
What's the difference between Fluid Framework and SignalR?
Where SignalR is a technology principally aimed at simplifying real-time communication between servers and clients, the Fluid Framework further abstracts that communication and, more significantly, focuses on distributing state between multiple clients. So, while you might use Fluid to solve some of the same problems you solve with SignalR today, the two are not interchangeable. Notably, the server component of a Fluid solution is lightweight and general-purpose while a SignalR solution designed to distribute state would require additional server development.