Question

到目前为止，我在GraphQL AppSync项目上工作了6个月，到目前为止，我对这个概念已经相当熟悉了。

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

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

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
    }
}

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

{
    "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次往返。

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

Answer 1

如果您要从突变中返回文章类型，则其值应与随后从其他查询中返回它时的值相同。

将突变视为将GraphQL从一种状态“变异”为另一种状态，然后（通常）将入口点返回到GraphQL可能具有更改的所有部分的功能。

我可以在评论对您的问题的答复中看到您担心性能。我的建议是，不要让性能成为对模型进行不良建模的理由，我在GraphQL上看到的几乎每个性能问题都具有解决方案，因此请专注于建模。

此外，您可能不想直接返回该文章，这限制了您包含其他更改的能力。假设用户类型具有一个publishedArticleCount非规范化字段，客户将需要知道何时更改，这意味着需要通过突变对其进行访问。因此，您可能需要执行以下操作：

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

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

这种有效载荷模式使随着时间的推移更容易更改突变的范围，而您的原始建模将您约束在相对狭窄的用例中。

GraphQL部分更新响应类型

1 个答案: