嵌套资源上的GraphQL突变

突变是操纵数据的查询。如果是的话我的root query和root mutation树应该看起来类似吧？他们都应该允许嵌套字段（嵌套突变）。我正在玩这个（使用express-graphql），它的工作原理。嵌套资源上的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 
    } 
    } 
}

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

来源

2015-11-06 xpepermint

我知道你的答案在GitHub上，它的不支持，但我很好奇，如果你真的放弃了这一做法，或者如果你坚持了下来，因为它似乎仍然工作。 – kaqqao

也许你可以从Graphcool嵌套突变API一些启示：https://www.graph.cool/docs/reference/simple-api/nested-mutations-ubohch8quo/ – sorenbs

该产品有一个唯一的ID，所以这就是所有你需要识别它。

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

要验证用户是否有权修改产品，您应该检查产品的项目。你可能会具有一定的集中授权反正：

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

    ... // update 
}

老答案：

这无疑是一个有效的例子。

我猜想缺乏嵌套对象变异的例子可能是由于这样一个事实，即使产品链接到一个项目，它在大多数情况下仍然有一个唯一的ID - 所以你可以找到产品即使没有项目ID。

另一种方法是包括该项目ID作为参数传递给updateProduct：

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

您的解决方案似乎是更好的给我，虽然。

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

我们宣布该方法的突变（而不是查询）作出明确，有些数据将要改变，但也有更重要的原因是：在你修改的数据是非常重要的顺序。如果你在一个请求中声明了多个突变，执行程序将依次运行它们以保持一致性（尽管这不会尝试解决分布式写入，但这是另一个问题）。

来源

2015-12-09 18:56:22

好，GraphQL的作者似乎不同意HTTPS ：//github.com/graphql/graphql-js/issues/221 – kaqqao

你的建议是危险的。请记住，正如本文（https://medium.com/the-graphqlhub/your-first-graphql-server-3c766ab4f0a2#bee6）所指出的，查询和突变之间最重要的技术差异是“ [...]突变是连续处理的，但查询没有做出这样的保证“。 –

嵌套资源上的GraphQL突变

回答

相关问题