fluid_列表和Fluid Framework为Microsoft Graph开发增添了动力

fluid

Microsoft 365是公司企业战略的核心。 Microsoft 365将熟悉的Office和SharePoint生态系统与Active Directory，Microsoft的系统管理工具及其安全产品相结合，并使用Microsoft Graph作为协作应用程序的基础，扩展了Microsoft的应用程序和开发人员平台。

Build 2020将Microsoft Graph置于Microsoft企业应用程序开发策略的中心，提供了旨在帮助构建协作应用程序的新工具和应用程序。 这个模型使我想起了Web 2.0的早期，那时可以将多个端点连接到新的Web应用程序中，并结合了雄心勃勃的早期协作工具，例如Dave Winer的先锋概述和博客平台Frontier。 今天，我们将基于协作图的应用程序包装成新的体验，无论是作为代码还是作为可用于构建自己的代码的API。

[ 同样在InfoWorld上：每个开发人员心血来潮的17个聪明的API ]

清单介绍

此策略的关键要素是一个新的基于Microsoft Graph的应用程序Lists 。 列表是Microsoft Graph中的主要数据类型，“列表”应用程序是如何围绕列表数据构建列表管理工具的示例。 现有模板使与同事快速建立和共享列表变得容易，就像在Outlook或“待办事项”中处理任务一样。

列表等英雄应用程序只是故事的一部分。 Lists提供的应用程序模型，以及可用于在其之上构建的API和工具，可能更重要。 其中一部分是可以将列表快速嵌入Power Apps和Power Automate中的功能，从而可以轻松地快速使用列表，将其作为自定义低代码体验的一部分，可由具有Excel Macro技能水平的任何人进行汇编。

将列表构建到自己的应用中

使用列表是学习Microsoft Graph的好方法。 它们是任何应用程序中的基本构建块，也是处理信息的强大方法。 Microsoft在Graph Toolkit中提供了一组Web组件来简化关键的交互 ，因此您可以使用几行代码来实现登录和显示信息。 该模型可在所有Graph SDK上复制，并具有用于列表的REST API，该API以 JSON形式提供结果，可在您自己的代码中使用。

用户将能够在列表应用中创建和管理列表，并将列表数据存储在图中并可从图中访问。 通过使列表成为Microsoft 365的一部分，您无需考虑安全性或合规性。 这些元素内置在平台中，并由Microsoft 365租户管理员管理。

成功的协作体验（例如列表）有一个基本的构建基块：低延迟的用户体验。 如果您看不到别人在做什么，那么您就需要避免使用冲突的风险，因为主动锁定和定期同步会破坏用户流。 没有用户之间的低延迟连接，在等待PC赶上协作者时，工作将变成一系列的停止/开始编辑。 这足以使您回到将文档副本通过电子邮件发送给团队中的每个人，并在所有文档归还后整理整理。

使用Fluid Framework的低延迟协作

微软一直在通过其Fluid Framework来解决延迟问题的解决方案。 基于预览列表的Fluid应用程序显示了几个人如何可以在Web上进行协作而几乎没有滞后。 这是一个有趣的示例，说明可以使用Microsoft属性上的Fluid Framework完成操作。 真正的测试将在Microsoft向您自己的应用程序开放Fluid时来，这最终将在Build 2020上进行。

实际上，事情正在进一步发展。 Microsoft不仅为Microsoft 365应用程序开发提供了对Fluid Framework组件和API的访问权限，而且还公开采购了它们以及构建和运行多用户应用程序所需的服务基础结构。 开源的Fluid Framework将包括连接端点和服务器的中继服务，以及填充内容的动态数据结构。 无论是在Web上还是在桌面代码中，在自己的应用程序中添加对实时通信和协作的支持，都应像用其Fluid Framework等效项替换现有数据结构一样容易。

正如微软发言人告诉我的那样：“有了第一套Fluid Framework开放源代码，开发人员将能够利用和利用协作元素-协作时跨浏览器的同步数据结构。 开发人员还可以构建Fluid Framework组件，并在自己的应用程序和页面中对其进行测试。” 重要的是要注意，开源Fluid Framework不会依赖于Microsoft 365；它不会依赖Microsoft 365。 您可以将其与任何RESTful Web服务一起使用。

构建下一代工作流应用程序

有了Fluid Framework和Microsoft Graph中的列表结构，开发新一代协作工具的范围就很大了，这些协作工具可以体现小型团队的日常交互。 并非每个业务流程都需要复杂的UI甚至复杂的数据结构。 他们确实需要团队协作和共享内容的简便方法。 更重要的是，他们需要一个通用的数据模型，该模型允许将应用程序快速扩展到其他业务流程和应用程序中。

例如，您可以使用指向Lists API的链接来填充团队，使其成为GitHub驱动的构建管道的一部分，自动记录拉取请求，并使用该请求将任务分配给开发团队成员。 如果有文档任务，可以在Fluid Framework应用程序（可能作为Visual Studio Code扩展托管）中打开Markdown文件，并将结果数据保存到图形中并推送到Azure devops管道。

我最近与Microsoft 365协作公司副总裁Jeff Teper谈到了Lists和Fluid。 他想到了“像REST plus plus这样的流体。 我们认为正是这一层将有助于解锁各种后端应用程序，不同的前端和后端的创建。” 正如他指出的那样，开源Fluid是其中的一部分，“这实际上是两件事：第一，它启用了Microsoft 365中的许多功能，以便开发人员可以在我们的存储基础上进行构建，但是我们希望慷慨地创建一个不依赖Microsoft 365的Fluid创新飞轮。”

解构SharePoint

微软的Graph策略还有一个有趣的方面，因为它的许多功能（如列表）已作为SharePoint功能提供。 将列表作为其自己的Microsoft 365应用程序和一组Graph API进行捆绑打包，意味着您可以将这些功能部署到用户，而无需承担整个SharePoint网站的开销。 无需导航到网站的一部分。 您所需要的只是Lists Web或移动应用程序，以查看可用的内容。

考虑此类技术的最佳方法也许是作为一组基础要素，为知识工作者提供等效的业务流程自动化，为他们提供现成的应用程序，用于快速开发的低代码工具以及定制工具的API。 如果您可以使用预建的列表应用，请使用它。 但是，如果它不能满足您的要求，或者您可以看到一种围绕它进行工作流自动化的方法，则Microsoft将提供构建自定义代码所需的工具。

如果说旧的SharePoint是美食大餐，那么Microsoft Graph和Fluid Framework就是分子美食，它可以从各个部分中解构并构建出新的东西。 尽管无需成为厨师，但任何人都可以烹饪新的东西。

翻译自: https://www.infoworld.com/article/3543764/lists-and-fluid-framework-add-fuel-to-microsoft-graph-development.html

fluid