Lists and Fluid Framework add fuel to Microsoft Graph development

Microsoft 365 is at the heart of the company’s enterprise strategy. Mixing the familiar Office and SharePoint ecosystem with Active Directory, Microsoft’s system management tools, and its security offerings, Microsoft 365 also extends Microsoft’s application and developer platform, using the Microsoft Graph as a foundation for collaborative applications.

Build 2020 puts the Microsoft Graph at the center of Microsoft’s enterprise application development strategy, with new tools and apps that are designed to help build collaborative applications. It’s a model that reminds me of the early days of Web 2.0, when it was possible to connect multiple endpoints into new Web apps combined with early ambitious collaboration tools like Dave Winer’s pioneering outlining and blogging platform Frontier. Today, we’re wrapping collaborative graph-based applications in new experiences, either as code or as APIs you can use to build your own code.

Introducing Lists

One key element of this strategy is a new Microsoft Graph-based application, Lists. Lists are a primary data type in the Microsoft Graph, and the Lists app is an example of how you can build a list management tool around list data. Existing templates make it easy to quickly build and share lists with colleagues, much like working with tasks in Outlook or To Do.

A hero application such as Lists is only part of the story. Perhaps more important is the application model that Lists provides, and the APIs and tools that can be used to build on top of it. Part of that is the ability to quickly embed lists in both Power Apps and Power Automate, making it easy to quickly use lists as part of custom low-code experiences that can be assembled by anyone with an Excel Macro skill level.

Building Lists into your own apps

Working with Lists is a good way to learn the Microsoft Graph. They’re a fundamental building block in any application and a powerful way to work with information. Microsoft provides a set of Web components in the Graph Toolkit to simplify key interactions, so you can use a couple of lines of code to implement log-ins and display information. That model is replicated across all the Graph SDKs, with a REST API for Lists that delivers results as JSON, ready for use in your own code.

Users will be able to create and manage lists in the Lists app with list data stored in and accessible from the graph. By making Lists part of Microsoft 365 you don’t need to think about security or compliance; those elements are built into the platform and managed by Microsoft 365 tenant administrators.

There’s one essential building block for successful collaborative experiences such as Lists: a low-latency user experience. If you can’t see what someone else is doing, then you need to avoid the risk of conflicts, with aggressive locks and regular synchronizations that break user flow. Without that low-latency connection between users, work becomes a succession of stop/start edits while you wait for your PC to catch up with your collaborators. It’s enough to drive you back to emailing copies of documents to everyone on a team and collating edits when they’re all returned.

Low-latency collaboration using the Fluid Framework

Microsoft has been teasing its solution to the latency problem for some time now, with its Fluid Framework. A preview list-based Fluid application shows how several people can collaborate over the Web with very little lag. It’s an interesting example of what can be done with the Fluid Framework on Microsoft properties. The real test will come when Microsoft opens Fluid up to your own applications, something that’s finally happening at Build 2020.

In fact, things are going a lot further. Microsoft is not only giving access to the Fluid Framework components and APIs for Microsoft 365 application development, it’s open sourcing them and the service infrastructure needed to build and run multiuser applications. The open source Fluid Framework will include the relay service that connects endpoints and servers, along with the dynamic data structures that populate content. Adding support for real-time communications and collaboration in your own applications, whether on the Web or in desktop code, should be as easy as replacing existing data structures with their Fluid Framework equivalents.

As a Microsoft spokesperson told me, “With the first set of Fluid Framework open source, developers will be able to leverage and build upon the collaboration elements—synchronized data structures across browsers as they collaborate. Developers can also build Fluid Framework components and test them within their own apps and pages.” It’s important to note that the open source Fluid Framework won’t depend on Microsoft 365; you can use it with any RESTful Web service.

Building a next generation workflow application

With Fluid Framework and with list structures in the Microsoft Graph, there’s a lot of scope for developing a new generation of collaboration tools that can embody the day-to-day interactions of small teams. Not every business process needs a complex UI or even complex data structures. They do need an easy way for teams to collaborate and share content. More importantly they need a common data model that allows applications to be extended into other business processes and applications quickly.

For example, you could use a link to the Lists API to populate a team to do as part of GitHub-driven build pipeline, automatically documenting pull requests and using that to assign tasks to development team members. If there’s a documentation task, Markdown files could be opened in a Fluid Framework application (perhaps hosted as a Visual Studio Code extension), with the resulting data saved into the graph and pushed to an Azure devops pipeline.

I recently spoke to Jeff Teper, corporate vice president of Microsoft 365 Collaboration, about Lists and Fluid. He thinks of “Fluid like REST plus plus. It is this layer that we think will help unlock the creation of all sorts of back-end applications, different front ends, and back ends.” Open sourcing Fluid is part of this, as he noted, “So it’s really two things: One, it’s enabling a bunch of features in Microsoft 365 so that developers can build on them with our storage, but we wanted to be generous and create a flywheel of innovation around Fluid that’s independent of Microsoft 365.”

Deconstructing SharePoint

There’s another interesting aspect to Microsoft’s Graph strategy, in that many of its features such as Lists have been available as SharePoint features. Unbundling Lists as its own Microsoft 365 application and as a set of Graph APIs means you can deploy these features to your users without having the overhead of an entire SharePoint site. There’s no need to navigate to a section of a site. All you need is either the Lists Web or mobile apps to see what’s available to you.

Perhaps the best way to think of technologies like these is as a set of foundational elements for delivering the equivalent of business process automation for knowledge workers, giving them a mix of off-the-shelf applications, low-code tools for quick development, and APIs for bespoke tools. If you can use the prebuilt Lists app, use it. But if it doesn’t do what you want, or if you can see a way to automate a workflow around it, Microsoft is providing the tools you need to build that custom code.

If SharePoint of old was a gourmet dinner, the Microsoft Graph and Fluid Framework are molecular gastronomy, deconstructing and building something new out of the parts. Though instead of needing to be a chef, anyone can cook up something new.