GraphQL 部分更新响应类型

GraphQL partial update response type

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

但我遇到了一件事,教程或文档中根本没有解释。 return 类型的 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
        }
    }
}

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

目前有什么想法吗?

如果您return从突变中获取文章类型,它应该具有相同的值,就好像您随后从不同的查询中return它一样。

将突变视为 "mutates" GraphQL 从一种状态到另一种状态的函数,然后(按照惯例)return 是 GraphQL 所有可能发生变化的部分的入口点.

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

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

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

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

这种有效负载模式使您可以更轻松地随时间更改突变的范围,而您的原始建模将您限制在一个相对狭窄的用例中。