GraphQL查询列表时如何同步订阅以无遗漏获取所有数据项？

结论 #

你目前采用的先启动订阅、再执行查询，最后合并两者结果的方案，就是满足「不遗漏更新、无需手动去重」要求的通用最优方案，执行顺序绝对不能反过来。 #

时序逻辑说明 #

按照你的业务要求，两种执行顺序的对比如下：

• 先查询后订阅：查询发起、到订阅正式生效的时间差内产生的新增评论会完全丢失，完全不符合你「不遗漏更新优先级更高」的要求。如果要补这个漏洞，需要给数据增加时间戳/唯一游标，查询时返回当前最大游标，订阅只处理游标大于该值的更新，反而需要额外的去重、判序逻辑，复杂度高很多。
• 先订阅后查询：
  1. 先发起commentAdded(postId: xxx)订阅请求，订阅成功后本地临时维护一个缓冲区，存储这段时间收到的所有新增评论
  2. 立刻发起commentsByPostId(postId: xxx)查询，拉取当前全量的历史评论
  3. 查询结果返回后，先把全量历史评论写入本地列表，再把缓冲区的新增评论按时间顺序追加到列表末尾即可，后续订阅收到的新评论可以直接追加到列表
     这种逻辑天然不会漏更：订阅先启动，所以查询执行过程中产生的所有新评论都会被缓冲区接住；而且查询返回的是订阅生效后某一时间点的全量快照，快照前的更新已经包含在查询结果中，不需要额外去重。

可选优化方案 #

如果不限制通用方案，有两种更简化的实现：

1. 服务端支持带初始快照的订阅
   可以改造订阅的resolver逻辑，用户发起commentAdded订阅时，先一次性返回当前postId下的全量评论列表，后续再推送增量更新。这种情况下前端只需要发起一次订阅请求，不需要自己维护两次请求的时序，也完全没有漏更、去重的问题，缺点是需要服务端配合改造，不是跨端通用能力。
2. 用GraphQL客户端内置能力
   如果你使用Apollo Client、Relay这类标准化GraphQL客户端，它们的归一化缓存已经内置了查询+订阅的合并逻辑：比如Apollo的subscribeToMore方法，只要给评论加唯一ID字段，客户端会自动合并查询和订阅的结果，重复ID的数据会自动覆盖，不需要你手动维护缓冲区，就算时序有微小误差也不会出现重复数据。

内容的提问来源于stack exchange，提问作者Andrey