首页 文章

嵌套资源上的GraphQL突变

提问于
浏览 次
4

变异是用于操纵数据的查询 . 如果是这样，那么我的 root query 和 root mutation 树应该看起来相似吗？它们都应该允许嵌套字段（嵌套突变） . 我正在玩这个（使用 express-graphql ）并且它有效 .

例：

// PUT /projects/:project_id/products/:id
mutation {
  findProject(id: 1) { // make sure that project exists and we can access it before mutating data
    updateProduct(id: 1, name: "Foo") { // the resolve function receives a valid `project` as the first argument
      id
    }
  } 
}

这是一个有效的例子吗？突变是否应该像这样嵌套？如果不是，我该如何处理嵌套资源？我找不到任何可以改变嵌套资源的现实例子 . 所有示例仅在第一级定义突变（根突变上的字段） .

rest graphql graphql-js

1 回答

  • 0

    该产品具有唯一的ID，因此您需要识别它 .

    mutation {
  updateProduct(id: 1, name: "Foo") {
    id
  }
}

    要验证用户是否有权修改产品，您应该检查产品的项目 . 你可能还有一些集中授权：

    resolve({ id }, { user }) {
  authorize(user, 'project', Product.find(id).project) // or whatever

  ... // update
}

    老答案：

    这当然是一个有效的例子 .

    我猜测缺少嵌套对象变异的例子可能是因为即使产品链接到项目，它在大多数情况下仍然会有一个唯一的ID - 所以即使没有项目你也可以找到产品ID .

    另一种方法是将项目id作为参数包含在_1288586中：

    mutation {
  updateProduct(projectId: 1, id: 1, name: "Foo") {
    id
  }
}

    不过，你的解决方案对我来说似乎更好 .

    事实上，突变实际上与查询完全相同 . 唯一的区别是 resolve 函数通常包含一些永久性更改，例如修改某些数据 . 即使这样，突变的行为就像查询一样 - 验证args，调用解析函数，返回声明类型的数据 .

    我们声明这样的方法作为变异（而不是查询）来明确表示某些数据将被更改，但更重要的原因是：修改数据的顺序很重要 . 如果在一个请求中声明多个突变，执行程序将按顺序运行它们以保持一致性（虽然这不会尝试解决分布式写入，这是另一个问题） .

    回复于

相关问题