GraphQL:许多小的变异，还是一个大的变异？

Question

假设我是用户，我正在某个任意应用程序上编辑我的个人资料。该应用程序让我进行了一系列更改，完成后，我点击“保存”，我的个人资料就会更新。

在 GraphQL 中处理这样的大型更新的推荐最佳实践是什么？在我看来，有几个选择:

A) 许多小突变 .如果用户更改了 5 项内容(即姓名、电子邮件、用户名、图像、个人简介)，则客户端可以向服务器发出 5 次更改。

优点:更小，更孤立的操作。

缺点:这不会违背 GraphQL 中“到服务器的往返行程”的目的，因为它需要...... 5？

B) 很多小的变异，叫服务器端 .与其从客户端调用 5 次变更(需要 5 次往返)，您还可以将数据 blob 发布到服务器，并使用一个函数来解析它，并对其找到的数据运行单独的变更。

优点:往返一次

缺点:我们必须向应用程序添加另一个层来处理这个问题。随着时间的推移，新功能会变得困惑、难以测试且难以维护。

C) 一个大突变 .用户通过单个变更将数据 blob 发送到服务器，该变更在文档上批量设置新数据，而不是在每个字段上运行单独的变更。

优点:DX；一个往返。

缺点:由于字段是作为参数传入的，这会导致应用程序受到攻击。恶意用户可以尝试传入任意字段，设置不应更改的字段(即 isAdmin 字段)等。突变必须很聪明才能知道允许更新哪些字段，并拒绝/忽略其余的部分。

我在网上找不到太多关于哪种方式是在 GraphQL 中做这种事情的“正确方式”。希望在这里找到一些答案/反馈。谢谢!

Answer 1

A) Many small mutations. If the user changed 5 things (i.e., name, email, username, image, bio) the client could fire off 5 mutations to the server.

您可以在单个请求中执行多个更改。无需多次调用服务器。

下面是一个例子:

mutation {
  setUserName(name: "new_name") { ok }
  setUserEmail(email: "new_email") { ok }
}

B) Many small mutations, called server-side. Rather than calling 5 mutations from the client, requiring 5 round trips, you could post a data blob to the server and have a function that parses it, and runs individual mutations on the data it finds.

当你改变多个字段或一次执行多个查询时，这正是 GraphQL 为你所做的。

C) One large mutation. The user sends the data blob to the server via a single mutation, which sets the new data in bulk on the document rather than running individual mutations on each field.

即使您使用多个字段，您仍然可以批量设置数据。
这将要求您将请求传递给中间件，而不是直接更新数据库，该中间件将在执行所有突变解析器后构建并执行单个查询。

Cons: Since fields are being passed in as arguments, this open the application to attack. A malicious user could try passing in arbitrary fields, setting fields that shouldn't be changed (i.e. an isAdmin field), etc. The mutation would have to be smart to know which fields are allowed to be updated, and reject / ignore the rest.

您不应该使用任意变量，而是将所有允许的属性作为参数列出。