GraphQL 模式设计 - 上下文相关字段

Question

我一直在努力寻找在 GraphQL 中对“上下文相关”字段进行建模的正确方法。 这是工作流系统的数据结构示例。 文档在工作流程中通过不同的步骤：

workflow {
  steps {
    name
  },
  documents {
    type,
    step {
      name,
      actionToComplete
    }
  }
}

大部分都是直截了当的。 一个工作流有多个步骤。 在一个工作流中有多个文档。 每个文档都在某个步骤中。 要进入下一步，用户需要完成一个操作。

我正在努力解决的问题是actionToComplete字段。 该字段的值由查询它的上下文决定。 因此，根据登录用户、他在系统中的角色和文档（其类型、是否包含敏感信息、附件等），确定actionToComplete 。 actionToComplete字段仅在查询 Document 上下文中的 Step 时相关。 仅查询工作流的所有步骤时，它并不相关，因为它不包含任何有意义的数据。

我正在努力解决的问题：

• 'actionToComplete' 字段的值只能在从文档中查询 Step 时确定。 在查询工作流的步骤时，我们无法提供此字段，因为我们缺少文档上下文。
• 您可能会争辩说 'actionToComplete' 字段应该移到 Document 本身。 这似乎与人们如何看待这一点产生了脱节。 自然要问的问题似乎是“我需要采取什么行动来完成文档所在的步骤？” 而不是“我需要在文档上完成哪些操作？”。 当更多的字段被推送到文档时，数据结构也会变得不那么结构化。
• 我们应该创建 Step 的上下文特定版本吗？ 然后，文档的步骤字段可以返回包含“actionToComplete”字段的特定于上下文的 DocumentStep 类型。 工作流的步骤字段将返回常规步骤类型的列表。 这感觉不对，因为 Step 和 DocumentStep 类型完全相同，只是从不同的上下文中查看

有人对如何建模这样的东西有任何建议吗？

Answer 1

我个人认为将字段移动到Document类型没有任何问题——您可能想多了。 该字段仍然与文档相关，即使在概念上它也与步骤相关。 如果每个文档有多个步骤，情况会有所不同，但这里的情况并非如此。 我也并不真正将数据扁平化视为主要问题。

也就是说，这是显式创建两个独立类型的一个很好的用例。 拥有代表相同域模型的不同类型非常好，特别是如果您需要根据父字段公开不同的字段。 我们倾向于避免模式中的重复，但在这种情况下，这是完全合理的。