GraphQL Resolvers嵌套场景下获取父级List节点ID的实现方案

当前场景适配GraphQL执行逻辑的核心矛盾是：字段解析为严格的自外而下顺序执行模型，每个层级的resolver仅能获取上一层返回的父级入参，无法反向回溯更上层没有主动传递的业务数据。找不到listId的根源，是中间层解析users字段时，丢弃了上游list节点携带的维度信息，没有把计算下游字段需要的关联参数顺着执行链路向下传递。

适配多对多关联关系的最稳妥方案，是在解析上层users字段时主动绑定list维度信息向下传递，完全匹配GraphQL的执行流程，不需要做自定义的AST解析或者全局上下文hack：

• 顶层getLists resolver保持原有逻辑：拉取全部列表实例，返回包含listId在内的所有列表业务数据，作为下一层users字段resolver的父级入参。
• 重写List类型下users字段的resolver：
  • 该resolver的父级入参就是当前正在解析的list实例，天然可以拿到当前的listId
  • 按正常业务逻辑查询当前list关联的所有用户
  • 不返回纯用户实体，而是把当前listId作为临时字段绑定到每个用户对象上，再返回给下游resolver
• 下游的stats、sum字段resolver，直接从父级入参中获取绑定的listId，结合本身的userId，即可精准定位对应维度的统计值。

// List 类型下 users 字段的 resolver
users: async (parent, args, context) => {
  // parent 即当前解析的list节点，直接获取当前listId
  const currentListId = parent.id
  // 查询该list关联的所有用户
  const userList = await context.dataSource.getUsersByListId(currentListId)
  // 携带当前listId返回，供下游resolver使用
  return userList.map(user => ({
    ...user,
    __boundListId: currentListId
  }))
}

// Stats 类型下 sum 字段的 resolver
sum: async (parent, args, context) => {
  // parent 即当前解析的stats所属的用户节点，可同时获取两个维度参数
  const currentUserId = parent.id
  const boundListId = parent.__boundListId
  // 维度参数齐全，直接计算对应统计值
  return context.dataSource.calculateDimensionStats(currentUserId, boundListId)
}

• 不要尝试从info对象中反向回溯获取上层业务数据：info存储的是查询结构的AST、执行元信息，不包含已经解析完成的业务实体，反向回溯的实现复杂度极高且容易出错。
• 不要用全局context存储当前listId：同一请求内会并行解析多个list节点的字段，全局存储会导致不同节点的上下文互相污染，出现统计值串线的问题。
• 绑定在对象上的临时字段不会影响对外返回结构：GraphQL只会按照Schema定义的字段返回给客户端，自定义的临时字段会在输出阶段被自动过滤，不会造成接口结构污染。

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