嵌套資源上的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突變

回答

相關問題