Document? Library? A new kind of component? Microsoft had a hard time explaining what its Fluid Framework is

Real-time collaboration in Office 365 but .NET developers sidelined in favour of JavaScript

Build An intriguing technology preview at Microsoft's just-finished Build event is Fluid Framework – but the company has not done a great job of communicating what exactly it is.

Microsoft opened up on the Fluid Framework a year ago at Build 2019. It is presented as a feature of Office 365, by which document components such as formatted text, tables, charts, and lists are enabled for real-time collaboration.

It is web technology so not yet available in the desktop Office applications – this is planned in future – but the idea is that if one works in the browser one can have these components in emails or other documents and see them update instantly as others contribute. This has been in limited preview for a while, but at Build Microsoft said a public preview is coming soon, and the framework will be published as open source within a month. This will allow third parties to create new components, or make use of the technology within non-Office applications.

How is this different from the multi-user editing capabilities already available in SharePoint online? "Fluid components by being embeddable within Teams chats and email will get you closer to a single source of truth," Mike Ammerlaan, Microsoft 365 Ecosystem director, told The Reg. "By being able to have those components directly inside of chat, you'll make it easier for users to see the latest version. It's more friction-free compared to a hyperlink."

The system records who made what change, and lets you see the component history and revert to an earlier version if needed.

Fluid is also, in the current implementation, a new document type that you can create in SharePoint or OneDrive online, which are containers for Fluid components. This piece is being typed into Fluid, and while it lacks the bazillion features of Word, it is a clean and responsive editor with basic right-click formatting, based internally on Markdown. Click the Plus icon and one can insert elements including tables, images, task lists, and @mentions. It is very limited.

Inserting a new component in the current underwhelming preview

The idea, though, is not so much a new document type, but rather to escape from the idea of editing a specific type of document. In the old model, "typically you task-switch between a lot of different applications," principal lead program manager Peter Allenspach told Build. "With the Fluid Framework you can have an integrated experience, we bring the tools to where you already work. For example, you can work in Teams or in Outlook end-to-end."

While this sounds interesting, there is frustration at the length of time it is taking Microsoft to progress from proof-of-concept demos to anything useful. One comment complained, for example: "Where is the real-life usage examples? Is it still so far in development that you don't have any? Like when will I be able to say copy a graph from a spreadsheet from OneDrive and paste it into email and then see it automatically refreshes live in an email reading pane when someone updates the numbers? Or even update the numbers directly from this graph in an email? One year, two years from now?"

Fluid Framework under the hood

What is the Fluid Framework really, though? The clue is in the name: it is a developer framework for creating real-time collaboration applications using JavaScript or TypeScript. It uses the WebSocket API so that clients are notified of updates and can send updates back to the server via an open communication session, which is much quicker and more lightweight than HTTP posts and gets.

The best information on Fluid is in this Build session where Allenspach and senior program manager Tyler Butler explained the rationale and how it works.

The heart of Fluid (on the client) is Distributed Data Structures, which have lots of built-in smarts

Fluid has two key concepts, said Butler. The first is distributed data structures (DDS), "the primary building block that you use as a developer". These include strings, arrays, lists of objects, and more. A Fluid component is a collection of DDSes combined with business logic and possibly other Fluid components. The framework lets developers store data in a DDS and have this state automatically stored on the server with other clients notified of the change. There are also methods for exploring component history, and a complete record of all changes is kept on the server.

At a Q&A session during build, principal program manager Nick Simons was asked whether C# developers can use Fluid in applications. "The Fluid Framework is designed to work with JavaScript runtimes," said Simons. "However, you can host a JavaScript runtime in a C# project." That is a hint, perhaps, that this is not really for .NET developers. Microsoft has a real-time communications library for .NET called SignalR, which has some overlap with what Fluid offers, but the company said that SignalR is not used in Fluid. React developers will feel at home, and this may be a clue concerning why the Office team at Microsoft seems to prefer React Native over .NET, especially as the company has now announced React Native for macOS alongside Windows.

How does the framework deal with conflict resolution? "It does require some thought" from the developer, said Simons, "but there's work in the design to make conflict resolution easy to handle... many of the distributed data structures have a certain amount of conflict resolution built into them, like the shared string, [which] do the work to make sure you get a rational output when multiple operations come in at the same time."

Where is the data stored? "It's largely up to the implementor," said Simons, though Microsoft is using SharePoint initially for Fluid documents. There are two distinct aspects to data storage, with the client file containing the JavaScript that defines the components, and a server that keeps track of operations (ops) that change their state – you can be sure that part is not done by SharePoint. "There are no DDSes being kept on the server," said Simons. "The server is simply responsible for managing ops and broadcasting ops. The clients are responsible for building the data structures from those operations."

How well does it scale? "The amount of work the server has to do is extremely lightweight," said Simons."It's just bringing in ops, stamping them, and broadcasting them. You can have a server do thousands of requests a second and it wouldn't be struggling at all. We find the network is the biggest factor."

The bottom line, then, is that Fluid Framework is both a new feature of Office 365, and a JavaScript library for real-time collaboration, soon to be open source. How useful will it be in Office? Most users still work in the desktop applications where Fluid does not run, and while we have seen some pretty demos, the business value is uncertain.

It is obvious, though, that it works much, much better for simultaneous co-authoring than the existing SharePoint-based capability, which may eventually help change the perception that Google's G Suite is superior for collaboration, and is evidence that Microsoft is willing to offer web-based features that leave Windows users behind. ®