![]() The Fluid service is designedįrom the ground up to be extremely scalable. When thinking about scale there are two key factors: service scale and client scale. ![]() How do you design Fluid Framework solutions to scale? editors.Īdding viewers scales far more than adding editors because each editor increases the volume of changes and viewersĭo not. When considering scale forįluid solutions, consider how well the client can handle and render changes, not whether the service is able toĪlso, there is a significant difference in capacity depending on whether users are purely viewers vs. TheĮxperience on the client will vary depending on the Fluid data store and local device. A more sophisticated implementation can distribute the work and support 1000s. Because the Fluid service is extremely lightweight, even a simple implementation of the service can How many concurrent users does this support? However, the Fluid runtime manages all of the connections so that Fluid client developers can focus on local experiences. But for each Fluid experience, there is onlyįluid clients connect to the Fluid service using the WebSocket protocol. Note, there isn’t a centralized Fluid service for all Fluid experiences. The ops are ordered, and because each client is running the same code, the DDSes in each client eventually end up in an Responsibility is sequencing all the incoming Fluid operations and then broadcasting them to all clients. In order to keep all clients in sync, they must be connected to a Fluid service. Location in a file structure, but because these experiences rely on the Fluid service, downloading the files and It is important to note that these files share many of the properties of a normal file such as permissions and a Using persistent storage allows a Fluid solution to persist across sessions.įor example, current Microsoft 365 Fluid experiences save ops in. This could be aĭatabase, blob storage, or a file. Persistent storage is a record of ops (and summary ops) saved outside of the Fluid service. ![]() ![]() Sessions later and for efficiencies when saving to persistent storage. Session storage also includes ops that summarize all past operations to improve performance for clients that join This record is used by the Fluid clients to produce identical local instances of the DDSes. Session storage is managed by the Fluid service and is, essentially, a central record of all the operations (ops) There are two classes of data storage to discuss when answering this question: session storage and Requires thought, just as it does when working with local data. DDSesĬan contain text, images, and other binary data and can effectively be any size. 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.ĭevelopers can use the DDSes included with the Fluid Framework or develop new ones.Īny practical limits on the types of data and size of a DDS will be specific to the implementation of that DDS. The data source for a Fluid solution can represent numerous DDSes. The same way they would operate on local data. That the Fluid runtime is able to keep them in sync across clients while each client operates on the DDSes in largely DDSes are the foundation of the Fluid Framework. Distributed Data StructuresĭDS is short for distributed data structure. The Fluid Framework was designed with performance and ease of development as top priorities. The Fluid Framework manages connections to services and keeps allĬlients in sync so that developers can focus on the client experience. Patterns similar to those used to work with local data. These librariesĪllow multiple clients to create and operate on shared, synchronized distributed data structures (DDSes) using coding The Fluid Framework is a collection of client libraries for building applications with distributed state. The following are short, sometimes superficial, answers to some of the most commonly asked questions about the Fluid Total order broadcast & eventual consistency Tutorial: Writing a TokenProvider with an Azure Function
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |