Apollo Kotlin 缓存中数组字段合并问题的解决方案

问题背景

在 Apollo Kotlin 4.0.0-beta.4 版本中，当使用规范化缓存(Normalized Cache)时，开发者遇到了一个常见问题：包含数组字段的对象在多次查询后被覆盖，而不是合并。具体表现为：

1. 数据结构中包含数组字段（如 books 和 someObjects）
2. 同一对象可能通过不同查询返回
3. 每次查询可能返回数组的不同子集
4. 当前行为是后接收到的数据会完全覆盖缓存中的旧数据

技术分析

Apollo Kotlin 的规范化缓存默认采用"最后写入优先"的策略，这对于标量字段是合理的，但对于数组字段，开发者通常期望的是合并而非覆盖。这种场景在以下情况特别常见：

• 分页查询
• 按不同条件过滤的查询
• 从不同端点获取同一对象的部分数据

解决方案

方案一：手动合并策略

使用 ApolloStore API 手动处理合并逻辑：

1. 在每次查询执行后，手动获取缓存中的现有数据
2. 将网络返回的新数据与缓存数据合并
3. 将合并后的结果写回缓存

这种方案需要开发者在所有可能返回该类型对象的查询处都实现合并逻辑，虽然灵活但维护成本较高。

方案二：使用实验性合并API

Apollo Kotlin 提供了实验性的合并策略API（标记为 incubating），专门设计用于处理这类场景：

1. 实现自定义的合并策略
2. 配置缓存使用该策略
3. 系统会在需要合并对象时自动调用策略

这种方案更符合关注点分离原则，合并逻辑集中在一处，但需要注意：

• API 尚处于实验阶段，未来可能有变更
• 需要额外依赖 incubating 模块

依赖配置注意事项

在实现方案二时，开发者可能会遇到依赖冲突问题，这是因为：

• 主模块已经包含了规范化缓存的基础实现
• incubating 模块提供了增强功能
• 两个模块包含部分相同类

解决方案：

1. 确保只依赖必要的模块
2. 使用新版依赖坐标（从 4.0.0-rc.1 开始，incubating 模块已独立）

最佳实践建议

1. 对于生产环境，建议先采用方案一，等 incubating API 稳定后再迁移
2. 合并逻辑应考虑：
   • 数组元素的唯一性（基于ID去重）
   • 合并顺序（新旧数据的优先级）
   • 可能的分页信息保留
3. 充分测试合并后的缓存状态是否符合预期

总结

处理规范化缓存中的数组字段合并是 GraphQL 客户端开发的常见需求。Apollo Kotlin 提供了不同层次的解决方案，开发者可以根据项目阶段和稳定性需求选择合适的实现方式。随着 incubating API 的成熟，这一问题将会有更优雅的解决方案。