GraphQL resolvers结构设计咨询：单查询兼容销售额对比/非对比场景

现有两个方案的优缺点 #

方案1 #

• 优势：diff与value两个字段职责完全独立，resolver之间无依赖，实现成本低，前端按需请求即可，不需要处理参数关联逻辑。
• 劣势：存在明显的语义和计算冗余：diff返回的main_value与同级value字段内容完全一致，如果前端同时请求两个字段会触发重复计算，浪费服务端算力。

方案2 #

• 优势：语义更符合直觉，主时间段销售额作为基础字段，对比数据作为扩展字段可选请求，完全贴合GraphQL「按需获取数据」的设计原则，没有冗余字段定义。
• 你担心的resolver依赖问题完全可以实现：GraphQL的resolver执行顺序为父级优先，父级resolver计算完成的主时间段value可以直接挂在返回对象上，子级compare的resolver可以直接读取父级返回的主值，再根据传入的compareRange计算对比值和差值即可，没有技术障碍。

更优的兼容方案 #

如果不需要重构原有接口结构，最小改动的方案是直接调整现有Schema：

1. 将SomeFilterInput中的dateRangeCompare改为可选参数
2. 将SaleResult中的compare_value、difference字段也设为可选
3. resolver逻辑中判断如果请求没有传入dateRangeCompare，则只计算main_value，另外两个字段返回null即可

该方案完全兼容现有调用方，不需要新增接口，也不需要调整字段结构，开发成本最低。

选型建议 #

如果要在你提出的两个方案中选择，更推荐方案2，语义更清晰，也没有冗余计算的问题，长期维护成本更低。

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