Getting started with Azure Fluid Relay

At its recent Ignite event, Microsoft unveiled a new Office application: Loop. Built on its long-promised real-time Fluid Framework collaboration platform, Loop is a canvas that hosts components for shared work, providing a place to keep all the various pieces of a team’s project together.

You could consider Loop to be the spiritual successor to one-time Microsoft Chief Software Architect Ray Ozzie’s work on Notes and Groove. Loop mixes documents, editing tools, and conversations so a team can construct documents while managing discussions around the content. It builds on the micro-work concepts we’re seeing in tools such as Teams, breaking down units of work and collaboration into components that can be inserted into Loop documents.

Microsoft Loop is Fluid

Loop’s component model uses the Fluid Framework to construct components, either as stand-alone Loop tools or as elements from another application. It’s possible to see Office collaborative tools like OneNote become collections of Loop components, while the Power Platform could deliver Loop endpoints as the end of flows or as outputs from Power BI or exports from the Dataverse object store.

However, Loop is only part of what the Fluid Framework offers. It’s not only a tool for Microsoft’s own products, it’s a way to build your own collaboration tools or to deliver real-time data to your users’ desktops. You can use the Fluid Framework as an alternative to technologies like SignalR to share state between multiple endpoints. This last part is perhaps the most important aspect of Fluid, as it’s a many-to-many, low-latency, distributed computing framework.

Sharing state between many different endpoints isn’t easy; doing it in real time is even harder. Most of the alternatives are one-to-one or one-to-many systems—they’re not managing state across dozens of users, and maybe as many different applications. I might use Loop to construct a collaborative document with you, but you may be producing data we need in Power BI, Word, Lists, or any other Microsoft 365 tool that’s Fluid-ready.

Relaying Fluid state with Azure

One key aspect of the Fluid Framework architecture is the relay that sits at the hub of all application collaborations. Although much of the work is managed by the client libraries as they collect and manage state, there’s still a need for a server to ensure that data is delivered correctly and that only authenticated clients have access to your content.

That’s where the Azure Fluid Relay comes in. Instead of building and running your own server to act as a collaboration hub, Azure offers a prebuilt managed solution that can be quickly deployed and used by your client-side code with minimal work on your part. The workflow remains simple, as state is managed by clients. All the server needs to do is listen for messages, sequence them appropriately, and then echo them back to all the clients. Client-side code then reconstructs the state.

If you’re familiar with how a database log table can reconstruct a database’s content when it’s replayed, you can think of the Fluid Framework as a distributed log and log-replay service. Every client logs its own state to the Fluid server, which acts as a distributed syslog client, saving the resulting aggregated log to all the clients.

Microsoft has launched a preview of the Azure Fluid Relay service with an associated set of Azure client libraries. This should match the current version of the Fluid Framework components, so your code can work with your own and the Azure services.

Setting up Azure Fluid Relay

To use the service, start by creating a Fluid Relay in an Azure resource group. Pricing is free during the preview, with no date yet for when it will move from preview to general availability. Like most Azure previews, it’s only available in a limited set of regions, so you may need to consider network latency if you’re working outside of Azure’s West US, West Europe, or Southeast Asia regions. There’s no service-level agreement during the preview, so use the service for experimentation and development as it’s not suitable for production code.

Setting up a relay is a matter of a few clicks and waiting for the service to deploy. Once deployed, you can access the IS and keys needed for client apps to connect to your relay. I’ve written about building Fluid apps in a previous column, and there’s little difference between running against a local development server and using Azure. Your main task when porting existing code to the service will be to add a tenant ID, an ITokenProvider instance that uses the primary key from the Azure service, and URLs for the orderer and storage services.

Microsoft provides sample code in the shape of an Azure Function that keeps your keys from appearing in client code. Using this tool, you’re able to add user details to the generated token, allowing you to track usage of your service in more detail. Working with the Azure client libraries, you can create containers for your service’s data, delivering a schema for the messages that your service will relay.

Working with the Azure Fluid Relay

Each container is perhaps best thought of as a definition of the collaborative space that’s implemented in the documents on each client. The container is the host for the distributed data structures that hold your application state. Code addresses the container endpoints in the relay, changing the content in a data structure. You need to consider how your code supports both concurrency and consistency, as you’re working in a distributed computing environment with low latency. That makes simultaneous writes a risk, so you need to choose an appropriate method of handling merges.

This approach allows you to build a custom Fluid environment for your application where the container describes your own specific document model, above and beyond those Microsoft offers. It’s associated with a services object that’s used to track the users currently working with the service. Your code can use the client libraries to get user data from the service object, displaying it as a live roster in your canvas. Events are triggered when users enter or leave the Fluid container, giving you a real-time view of the users alongside the real-time content.

One interesting option for Fluid using Azure is deploying your code as Azure Static Web Apps, building them into your git workflow. A Jamstack web app acts as a front end to Azure Functions that handle authentication, with client-side JavaScript connecting to your Fluid Relay.

The Fluid Framework is an intriguing approach to delivering collaborative, distributed applications. Moving much of the functionality to the clients reduces complexity significantly, so using a hosted server to manage and marshal your data lets you focus on delivering the best possible app to your users. Microsoft intends to keep the server, client libraries, and the protocol in sync, so if you do need to move to a private Fluid server, the same code can be used; all you need to do is change the endpoints.

For public applications using Azure, this is a sensible solution, especially when used in conjunction with tools such as Static Web Apps and Functions. The only question is how much it will cost when it comes out of preview. If it’s on a par with Microsoft’s other Azure message-based services such as Event Grid, you should be looking at less than a dollar for a million operations.