Microsoft’s Fluid Framework flows into general availability on Azure

Microsoft has gone live with its Azure Fluid Relay service to support real-time collaboration applications, available in around 10 Azure regions – half of which are in the US – on a pay as you go basis.

The service is built on WebSockets, a full-duplex communication channel supported by modern web browsers, faster and better suited to real-time communications than HTTP which is a unidirectional protocol. The innovation in Fluid Framework is that it supports distributed and synchronized shared state, so that creating a collaborative application is simplified.

A Fluid Framework application showing a distributed data model in use

Fluid Framework is open source under the MIT license. The client framework is easy to use but implementing a production Fluid server is more challenging. There is a reference open source server which runs in a Docker container, called Routerlicious, which according to the docs “you can use for development or as the basis for a production quality server.” However the docs add that “Routerlicious on its own is not production ready.” The Azure Fluid Relay service is a managed service that makes it easy to get up and running, whether for test and development, or for a production application.

Routerlicious: a complex server application

Fluid Framework is ideally suited to applications where multiple concurrent users do co-authoring, whether something as simple as a whiteboard application, or as complex as an engineering drawing. This latter case has attracted interest from Autodesk which has contributed to the project. The roots of Fluid Framework at Microsoft are probably to do with the challenges of simultaneous document editing in Office applications, and the poor performance of applications like Word and Excel in this respect, when compared to Google’s web-based document editing. The Fluid Framework actually has its own document format, .fluid, but this only works on OneDrive and SharePoint and is useless offline.

The only supported language for the Fluid Framework is TypeScript or JavaScript. “You can use the Fluid Framework with non-web technologies by leveraging a JavaScript runtime to host the Fluid code,” the docs say. That is a disappointment to .NET developers, who have an existing WebSocket-based framework called SignalR, but SignalR is not designed to abstract distributed state in the same way.

This initial release of the Azure Fluid Relay Service is limited to 100 concurrent users. The cost varies according to region, but one example is £1.50 per 1M operations in, £0.50 per 1M operations out, £1.50 per 1M client connectivity minutes, and £0.20 per GB per month storage. Each operation is a message of up to 2KB. How that works out in practice is hard to say, but an application with 100 clients all performing edits will no doubt send many hundreds of thousands of messages in a short space of time, so experimentation is recommended.

Fluid Framework does look interesting though it is a shame that enquiries like this one from March this year have gone unanswered. One key aspect is how Microsoft itself will use the technology. It is apparently already used by OneNote and Teams in some small way.