Question

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

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

其中大部分都是直截了当的。工作流程包含多个步骤。在工作流中，有多个文档。每个文档均处于特定步骤中。要转到下一步，用户需要完成一项操作。

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

我正在努力解决的问题

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

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

Answer 1

我个人认为将字段更改为git push origin v0.1.0类型不会有任何问题-您可能想得太多。该字段仍与文档相关，即使从概念上讲它也与步骤相关。如果每个文档有多个步骤，情况会有所不同，但实际情况并非如此。我也不认为将数据变得扁平化成为主要问题。

也就是说，这是一个显式创建两个单独类型的好用例。拥有代表同一域模型的不同类型是非常好的，特别是如果您需要根据父字段公开不同的字段时，尤其如此。我们倾向于避免在架构中重复，但是在这种情况下，这样做很有意义。

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

1 个答案: