北京
Jake Lazaroff 在休假时做过一个旅行规划应用，用 YJS 加上托管同步服务实现了多端协作。不到一年，那家同步服务提供商被收购并关停了服务。应用虽然还能在本地跑，但跨设备同步彻底失效，只剩下手动传文件这条路。这个例子戳破了一个让开发者不安的事实：那个帮你打通多设备的服务器，同时也成了整个协作链路里最脆弱的依赖项。Lazaroff 把这件事当作演讲的开场，不是为了抱怨某个供应商，而是想引出一个更根本的问题——我们能不能把应用最核心的协作能力，从随时可能消失的专用后端里抽离出来？
他的答案是 AT 协议（Authenticated Transfer Protocol）。过去大家谈论它，更多是把它看作支撑社交网络的底层设施，但 Lazaroff 认为，它同样可以充当分布式应用的底座，而且是一种本地优先的架构。在这种模式下，每个用户的数据存放在自己的个人数据服务器（PDS）里，应用只是获得授权去读写这些数据。PDS 包揽了存储、细粒度认证和推送更新这些脏活累活，而应用本身不必再自建一套独立的后端。标准的 AT 协议架构里还有一个按应用定制的“应用视图”（App View）服务器，Lazaroff 却直言它属于可选项，而且是整个技术栈里偏脆弱的环节。他随即抛出一个大胆的思路：干脆把 App View 也扔掉，只用静态应用、PDS 和中继（relay）能做出什么东西？
演讲的主体就是三个去掉 App View 的实验。
第一个实验是协作文本编辑器，用 YJS 和 ProseMirror 搭起来。每一条 YJS 更新都作为一条记录写入用户自己的 PDS，协作者则通过一条元数据记录串在一起。不同用户通过中继几乎实时地抓取并复制彼此的更新，这本是同步服务器的活，现在由 AT 协议全盘接管。Lazaroff 的说法很直白：这相当于把 AT 协议当成了 YJS 的同步服务器。但问题也随之暴露——文档状态散落在大量记录当中，别的应用想拿来互通就会变得很麻烦。
第二个实验转向协作待办清单，用的是 AT 协议原生的 CRDT（无冲突复制数据类型）记录。每条记录就是朴素的 JSON 对象，包含类型、清单 ID、文本、完成状态、创建时间等字段，CRDT 的元数据另外附加，不搅乱结构。这么一来，即使某个应用压根不认 CRDT 元数据，照样能读懂记录内容。冲突处理上，每个字段采用最后写入获胜的寄存器逻辑，并发编辑不同字段时互不打扰。棘手的情况发生在并发写入同一条记录时：比较并交换逻辑会直接拒绝写入，客户端接着拉取最新状态，在本地合并后再重试。这个设计要解决的核心难题，是如何在不丢更新、不破坏 CRDT 模型的前提下，处理对同一条记录的并发写入。
第三个实验同样拒绝了 App View，只依赖静态应用、PDS 和中继。Lazaroff 原本想演示 AT 协议在另一种协作场景中的表现，不过这一部分的细节在演讲里没有完全展开。尽管如此，前两个实验已经足够勾勒出一幅图景：把协作所需的基本能力下沉到协议层，并且由用户自己的数据仓库来承担持久化和认证的责任，应用的后端就可以一直薄下去。
回到开头那个旅行规划应用的遭遇。如果当初它把同步能力建立在 AT 协议之上，那个被收购关停的同步服务就不再是命门，因为同步已经变成了中继服务的一部分，而中继是可以由任何人来运行的。Lazaroff 所说的“减少对专用后端的依赖”，落到实处就是让应用中那些最容易产生强绑定的模块，拆解成一批可替换、可自托管的基础组件。这样拼出来的应用，即使某个组件下线，也坏不到根基。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
