GraphQL 部分更新响应类型答案

【问题标题】：GraphQL partial update response typeGraphQL 部分更新响应类型
【发布时间】：2018-11-30 21:47:43
【问题描述】：

到现在为止，我已经在一个 GraphQL AppSync 项目上工作了 6 个月，到目前为止我已经非常熟悉这个概念。

但我遇到了一件事，教程或文档中根本没有解释。 Mutation 返回类型的最佳实践是什么？（尤其是部分更新）

这是一个简化的示例架构：

type Article {
    uuid: ID
    title: String
    description: String
    price: Int
    tax: Int
    category_uuid: ID
    status: Int
    type: Int
}

input ArticleUpdateInput {
    uuid: ID!
    title: String
    description: String
    price: Int
    tax: Int
    category_uuid: ID
    status: Int
    type: Int
}

type Mutation {
    updateArticle(input: ArticleUpdateInput!): Article!
}

以下突变将是有效的：

mutation foo {
    updateArticle(input: {
        uuid: "c63c6dcb-6c09-4952-aae2-26e3fde47262",
        title: "BBQ Burger",
        price: 699
    }) {
        __typename
        uuid
        title
        description
        price
        tax
        category_uuid
        status
        type
    }
}

由于我只指定了标题和价格，因此响应的其他字段将为空，如下所示：

{
    "data": {
        "updateArticle": {
            "__typename": "Article",
            "uuid": "c63c6dcb-6c09-4952-aae2-26e3fde47262",
            "title": "BBQ Burger",
            "description": null,
            "price": 699,
            "tax": null,
            "category_uuid": null
            "status": null
            "type": null
        }
    }
}

避免返回这些空字段的最佳做法是什么？我应该在更新后触发 getArticle 查询并从数据库中返回整篇文章记录吗？我认为这会非常低效，因为如果您要添加 n 篇文章，那么数据库将有 2*n 次往返。

到目前为止有什么想法吗？

【问题讨论】：

你到底想做什么？您是否需要其他字段（description、status...）来填充数据，或者您根本不需要它们在响应中？您使用的是什么数据源？
@Tinou 我正在使用通过 lambda 连接到 AppSync 服务的 amazon rds (mysql) 实例。我的问题是，如果我只改变其中的几个字段，我应该如何处理响应中的剩余字段？例如，仅返回 uuid 会是一个很好的解决方案吗？在响应中提供所有类型的字段真的是最佳做法吗？如果是这样，我必须从数据库中获取剩余的字段还是我错了？
这真的取决于您的应用程序要求，如果您的前端只需要 uuid，那么您的变异输出可以只是一个String。如果您的应用程序需要整个 Article，那么您需要在更新后读取所有字段。

标签： graphql apollo aws-appsync

【解决方案1】：

如果您从突变返回 Article 类型，它应该具有与您随后从不同查询返回它相同的值。

将突变想象为一个函数，它将 GraphQL 从一种状态“突变”到另一种状态，然后（通常）返回 GraphQL 可能发生变化的所有部分的入口点。

我可以在对您的问题的评论回复中看到您担心性能。我的建议是不要让性能成为对架构建模不佳的理由，我在 GraphQL 中看到的几乎所有性能问题都有解决方案，因此请专注于建模。

此外，您可能不想直接返回文章，这会限制您包含其他更改的能力。假设一个用户类型有一个publishedArticleCount 非规范化字段，客户端需要知道它什么时候发生了变化，这意味着它需要通过突变来访问。所以你可能想做这样的事情：

type UpdateArticlePayload {
    article: Article!
    author: User!
}

type Mutation {
    updateArticle(input: ArticleUpdateInput!): UpdateArticlePayload!
}

这种有效负载模式可以更轻松地随着时间的推移更改突变的范围，而您的原始建模将您绑定到一个相对狭窄的用例中。

【讨论】：