zerotree.blogg.se - Fluid app github

#Fluid app github full#
#Fluid app github code#

In order for the client’s ops to be persisted, a server will be necessary for the data to be stored. There’s also a server component to the Fluid Service. The developer can focus on their client experience and let the Fluid Framework do the rest of the work for them. This gives teams a lot of flexibility to use the framework of their choice to implement this technology. One of the best parts of the Fluid Framework is that it will independently work with the most popular UI libraries, including React, Vue.js, and Angular.

#Fluid app github code#

With the Fluid Framework, client code can pull in libraries available on npm that handle all the heavy lifting. Persistent storage is a record of ops that is saved outside the Fluid Service (typically in a database or file). Session storage is managed by the Fluid Service running on the clients themselves. The way that it maintains the data state across any client is through session storage and persistent storage. Whenever an op is passed into the Fluid Service, it persists the change within the DDS that it occurred and then propagates the change to any connected clients. The Fluid Service takes in any change from the DDS within the client as an op (change). The Fluid Container also contains the Fluid Runtime, which includes Distributed Data Structures (DDS) that persist data to any clients connected to the application.

The Fluid Container contains all the logic that communicates with the Fluid Loader, which then communicates back with the Fluid Service.

#Fluid app github full#

Click here to see the full demo with network requests The Fluid Loader wraps a Fluid Container that houses all the mechanisms that allow clients to communicate with the Fluid Framework. When applications use the Fluid Framework, they start with the Fluid Loader. I’m borrowing the following graph from the Fluid Framework docs, and it provides an excellent visual: A diagram of the Fluid Framework architecture (original can be found here: ) The framework can be explained in the following terms: We can discuss the mechanics in a general sense, and you can also see it in action if you use apps like Microsoft Teams. For a quick intro to what this technology looks like in action, check out the demo that was shown at Build 2019:Īs I mentioned in the intro, the Fluid Framework has been around for some time and is present in many Microsoft apps that you see today. This post will introduce the Fluid Framework and then walk through a sample application to show how it can be integrated into your projects. The Fluid Framework provides helper methods and wrappers that enable your applications to have real-time updates.

Brainstorming and ideation apps like Microsoft Visio or flow chart toolsįluid’s main goal is to handle the piping and mechanics of real-time updates so that developers can focus on the experience rather than dealing with synchronizing messaging and data.

Apps that need to mark presence (show a person is online).

Shared projects (documents, presentations, etc.).

Example use cases for the Fluid Framework include: Now that the Fluid Framework has been open-sourced, the technology can be utilized within client applications both within the Microsoft ecosystem and beyond. This is different than the classic SignalR technology in that it not only broadcasts real-time updates through WebSockets, but it also maintains those updates in that data through what is called a Distributed Data Structure (DDS). The technology’s main use case is enabling collaboration and real-time updates across users. Microsoft uses the Fluid Framework in many of its popular apps, including Office 365 and Teams. Microsoft’s Fluid Framework is a new and exciting technology that has recently been open-sourced. Microsoft’s Fluid Framework: An introduction Andrew Evans Follow Husband, engineer, FOSS contributor, and manager at CapTech.