微软已经在Github上发布了其Fluid Framework的代码，该框架是用于实时协作Web应用程序的Typescript库。

Fluid Framework已经投入使用了一段时间。它在2019年5月的Build上进行了预览，然后在今年早些时候的Build 2020上进行了详细显示。微软当时表示将在一个月内将其开源，但已经花了四个时间。

Fluid Framework的用途是什么?编写文档网站时出现故障，以各种方式返回损坏的主页或错误消息，表明该网站似乎正在作为Azure静态Web应用程序运行，这无济于事。到异常高的使用率。” 由于静态Web应用程序可以很好地扩展，因此这不仅使Fluid Framework开发人员感到失望，而且还使Azure的一项新功能令人失望。毫无疑问，它将很快修复。

Microsoft Fluid Framework软件工程师Sam Broner 说：我们现在正在研究它。许多地区都在备份，但是只要有信心我们就会在这里进行更新。

Broner在宣传视频中将Fluid解释为构建“本机多用户应用”的简便方法，以及嵌入和共享“实时Web体验”的方法。它的实质是一个TypeScript客户端框架，该框架管理所谓的“分布式数据结构”，开发人员定义的自定义对象，以及一个广播和存储修改数据的操作或操作的服务器。与客户端的通信是通过WebSockets进行的，比HTTP更快，更轻便。微软已经表示，它在服务器上既低延迟又不需要，因此可以很好地扩展(我们希望比文档站点更好)。由于大多数智能工具都在客户端代码中，因此不需要自定义服务器代码。我们在这里看了一些细节。

Microsoft将其365服务中的框架用于协作文档，这些文档的性能和扩展性优于传统的Office共享创作。Microsoft 365拥有自己的Fluid服务器和.fluid文档类型。与其他Office文档不同，它完全基于云。无法下载文件并在本地进行处理。

一个FAQ文档澄清一些利弊。由于服务器存储了所有操作，因此浏览器可以关闭并重新加入会话并恢复最新状态。但是对于要在会话后仍然存在的数据，开发人员将需要将操作存储在数据库或文件中的某个位置。.fluid文件是一个示例，尽管这些文件仅适用于Microsoft365。该公司表示，至少支持100个并发用户，但它可以进一步扩展。

Fluid和SignalR(也基于WebSockets的.NET框架)有什么区别?微软表示，Fluid在服务器上更加轻巧，并且专注于“在多个客户端之间分配状态”。在某些情况下，您可以使用其中任何一种，但在服务器上需要更多逻辑的情况下，SignalR会更合适，而如果所有逻辑都可以在客户端上，则Fluid是合适的。回合制游戏是可能的，但是在某些情况下会很尴尬，因为客户端会强制执行规则，并且实际上拥有所有数据。

微软说：“在防止作弊方面可能要解决一些有趣的问题。”

该代码现在已获得MIT许可，位于GitHub上。我们在Mac上使用Visual Studio Code成功安装并运行了一个简单的示例，尽管在某些示例中出现了错误。该服务器在Node上运行，Microsoft注意到完整的测试覆盖范围在Windows上不起作用，这表明该公司与Windows根目录的距离有多远。

文档说： “ Fluid Framework与您选择的应用程序框架一起使用，无论您是喜欢直接的JavaScript还是喜欢React，Angular或Vue之类的框架。”

只要是JavaScript，任何框架都可以。NET呢?开发人员将需要一个JavaScript运行时来承载Fluid代码。Java的?同样适用。

尽管该代码现已发布，但仍处于预览状态。微软认为，支持Fluid Framework的核心技术已经成熟且稳定。 但是，在该基础之上构建的层仍在进行中。

流体很有趣，但是它对微软的现实价值仍然不清楚。Microsoft在设计时就考虑了实时协作文档编辑的问题，但是在尝试将其与Microsoft 365集成时，围绕与现有Office文档不兼容以及无法脱机工作的限制将成为问题。引人注目的用例可能会出现，并且该框架确实有潜力使开发人员将协作功能构建到Web应用程序中。