This article is more than 1 year old
Microsoft's Fluid Framework is now open source on GitHub
Distributed state in the browser made easy but there are snags for real-world use
Microsoft has published the code for its Fluid Framework on Github – a Typescript library for real-time collaborative web applications.
Fluid Framework has been in the works for some time. It was previewed at Build in May 2019, then shown in more detail at Build 2020 earlier this year. Microsoft said at the time it would be open source within a month, but it has taken four.
What is Fluid Framework for? It does not help that at the time of writing the documentation site is borked, returning variously either a corrupt home page, or an error message declaring that the site, which appears to be running as an Azure Static Web App, has been throttled “due to unusually high usage.” Since static web apps are meant to scale well, this is disappointing not only for Fluid Framework developers, but also as an example of one of Azure’s newer features. No doubt it will be fixed soon.
“We're looking at it now. Many regions are back up, but we'll update here once we're confident,” said Sam Broner, a Microsoft Fluid Framework software engineer.
Broner explained Fluid in a promotional video as an easy way to build “native multi-user apps” and as a way of embedding and sharing “live web experiences.” The essence of it is a TypeScript client framework that manages what are called “Distributed Data Structures”, custom objects defined by the developer, and a server that broadcasts and stores operations, or ops, that modify the data. Communication with the clients is via WebSockets, quicker and more lightweight than HTTP. Microsoft has said it is both low latency and undemanding on the server, so it scales well (better, we hope, than the documentation site). Since most of the smarts are in the client code, no custom server code is required. We took a look at some of the details here.
Microsoft is using the framework in its 365 service for collaborative documents that perform and scale better than traditional Office shared authoring. Microsoft 365 has its own Fluid server and a .fluid document type. Unlike other Office documents, it is purely cloud based. Downloading the files and working on them locally does not work.
A FAQ document clarifies some of the pros and cons. Since the server stores all the ops, a browser could close and rejoin a session and get back up to date; but for data that will persist beyond a session, the developer will need to store the ops somewhere, in a database or file. A .fluid file is one example, though these only work on Microsoft 365. The company said that at a minimum, 100s of concurrent users are supported, but it could scale further.
What is the difference between Fluid and SignalR, a .NET framework also based on WebSockets? Fluid is more lightweight on the server, said Microsoft, and focuses on “distributing state between multiple clients.” There are some cases where you could use either, but in instances where more logic on the server is required, SignalR would be a better fit, whereas Fluid is suitable if all the logic can be on the client. Turn-based games are a possibility, but awkward in some cases since the client enforces the rules and in effect has all the data.
“There may be some interesting problems to solve around preventing cheating,” Microsoft said.
The code is now on GitHub under the MIT license. We successfully installed and ran a simple example using Visual Studio Code on a Mac, though we got errors on some of the examples. The server runs on Node, and Microsoft has noted that the full test coverage does not work on Windows, an indication of how far the company has departed from its Windows roots.
Although the code is now published, it is still in preview. Microsoft reckons that the “core technology powering Fluid Framework is mature and stable. However the layers built on top of that foundation are still a work in progress.”
Fluid is interesting but its real-world value to Microsoft remains unclear. Microsoft designed it with real-time collaborative document editing in mind, but the restrictions around incompatibility with existing Office documents and inability to work offline will be issues as it tries to integrate this into Microsoft 365. Compelling use cases may yet emerge, and the framework does have potential for developers building collaborative features into web applications.®