At the recent Ignite event, Microsoft unveiled a new Office application: Loop. Built on the long-promised real-time Fluid Framework collaboration platform, Loop is a canvas that hosts shared work components and provides a place to keep all the different parts of a team project together.
You might think of Loop as the spiritual successor to one-time Microsoft Chief Software Architect Ray Ozzie’s work on Notes and Groove. Loop combines documents, editing tools, and conversations so a team can compose documents and manage content discussions. It builds on the microwork concepts we see in tools like 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 standalone Loop tools or as elements from another application. It’s possible to see Office collaboration tools like OneNote becoming collections of Loop components, while the Power Platform can provide Loop endpoints as the end of flows or as an output from Power BI or export from the Dataverse object store.
Loop, however, is only part of what the Fluid Framework offers. Not only is it a tool for Microsoft’s own products, it’s also a way to build your own collaboration tools or deliver real-time data to your users’ desktops. You can use the Fluid Framework as an alternative to technologies such as SignalR to share state between multiple endpoints. This last part is arguably the most important aspect of Fluid, as it is a many-to-many, low-latency, distributed computing framework.
Sharing status between many different endpoints is not easy; doing it in real time is even harder. Most alternatives are one-to-one or one-to-many systems – they don’t manage the state of dozens of users, and maybe as many different applications. I could use Loop to build a collaboration document with you, but you can produce the data we need in Power BI, Word, Lists, or any other Microsoft 365 tool that’s Fluid ready.
Report fluid status with Azure
An important aspect of the Fluid Framework architecture is the relay that is the hub of all application collaborations. While much of the work is managed by the client libraries that collect and manage state, there is still a need for a server to ensure data is delivered correctly and only authenticated clients can access your content.
That’s where the Azure Fluid Relay comes in. Instead of building your own server and using it as a collaboration hub, Azure provides a pre-built managed solution that can be quickly deployed and used by your client-side code with minimal work on your part. The workflow remains simple, because the status is managed by customers. The server just needs to listen for messages, arrange them appropriately, and then echo them back to all clients. Client-side code then reconstructs the state.
If you are familiar with how a database log table can reconstruct the contents of a database when replayed, you can think of the Fluid Framework as a distributed log and log replay service. Each client records its own state on the Fluid server, which acts as a distributed syslog client, and stores the resulting aggregated log for all clients.
Microsoft has released a preview of the Azure Fluid Relay service with an associated set of Azure client libraries. This must match the current version of the Fluid Framework components so that your code can work with your own and the Azure services.
Set 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, there is no date yet for when it will move from preview to general availability. Like most Azure previews, it’s only available in a limited number of regions, so you may need to consider network latency if you’re operating outside of the West US, Western Europe, or Southeast Asia regions of Azure. There is no service-level match during preview, so use the service for experimentation and development as it is not suitable for production code.
Setting up a relay is a matter of a few clicks and waiting for the service to be implemented. Once implemented, you can access the IS and keys needed to allow client apps to connect to your relay. I wrote in a previous column about building fluid apps and there is little difference between running on a local development server and using Azure. Your main task when transferring existing code to the service is to add a tenant ID, and
ITokenProvider instance that uses the primary key of the Azure service, and URLs for the ordering and storage services.
Microsoft provides sample code in the form of an Azure function that prevents your keys from appearing in client code. This tool allows you to add user data to the generated token so that you can track the usage of your service in more detail. By working with the Azure client libraries, you can create containers for your service’s data and provide a schema for the messages your service passes.
Working with the Azure Fluid Relay
Each container is perhaps best thought of as a definition of the collaboration space implemented in each client’s documents. The container hosts the distributed data structures that contain your application state. Code addresses the container endpoints in the relay, changing the content in a data structure. You should consider how your code supports both concurrency and consistency since you are working in a low-latency distributed computing environment. That makes concurrent writing a risk, so you need to choose an appropriate method to handle merges.
With this approach, you can build a custom fluid environment for your application where the container describes your own specific document model, on top of Microsoft’s offerings. It is associated with a services object that is used to track the users who are currently working with the service. Your code can use the client libraries to retrieve user data from the service object and display it as a live grid in your canvas. Events are triggered when users enter or exit the Fluid container, giving you a real-time view of the users in addition to the real-time content.
The Fluid Framework is an intriguing approach to delivering collaborative, distributed applications. Moving much of the functionality to the clients greatly reduces complexity, so using a hosted server to manage and organize your data allows you to focus on delivering the best possible app to your users . Microsoft plans to keep the server, client libraries, and protocol in sync, so if you 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 that use Azure, this makes sense, 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 the preview. If it’s comparable to Microsoft’s other Azure message-based services like Event Grid, you’d be looking at less than a dollar for a million operations.
Copyright © 2021 IDG Communications, Inc.