避免嵌套分页的模式设计

Posted 2023-03-08

【中文标题】避免嵌套分页的模式设计

【英文标题】：Schema design to avoid nested pagination

【发布时间】：2020-10-15 22:28:31

【问题描述】：

首先，我使用的是“Relay”分页的简化版本，其中“List”是“connection”的基本等价物，“limit”等价于“first”，“cursor”等价于“之后”。

这是我的架构的相关部分：

extend type Query 
    artist(id: ID!): Artist
    artists(limit: Int!, cursor: String): ArtistList!


type Artist 
    id: ID!
    account: Account!
    photos(limit: Int!, cursor: String): PhotoList!
    website: String
    instagram: String
    facebook: String
    created: Date!
    updated: Date
    about: String


type ArtistList 
    nodes: [Artist]!
    page: Page!

我想避免嵌套分页，所以希望在查询 artist 上允许获取 photos 的下一个节点，并且不允许在查询 artists 上获取 photos 的下一个节点（例如，允许参数 @987654326 @ of photos 查询 artist 并禁止查询 artists)。但我看不出如何在 GraphQL 模式中表达这一点。

【参考方案1】：

没有办法专门做你想做的事。您可以从artist（例如ArtistWithPagination）和artists（例如ArtistWithoutPagination）返回不同的类型。我不确定这是否值得用两种非常相似的类型进行权衡。

或者，当用户尝试以这种不受欢迎的方式（使用custom validation rule）查询 API 时，您可能会引发运行时错误。如果您的 GraphQL API 是内部的，您甚至可以开发一个 linter，它会在开发人员在查询中进行双重分页时发出警告。

【讨论】：

我认为这是不可能的，但我对 GraphQL 的经验很少，想确定一下。我将阅读有关validation 的文档。我正在考虑的另一种可能性是重新设计 API，永远不允许通过类型 artist 进行分页并获得相同的结果，对一个请求执行两个查询（我不确定这是否是正确的方法GraphQL 的视图，否则可能会出现问题）。

是的，您可以考虑单独查询photosByArtistId(id: ID!) 来获取照片。但是我不确定您是否真的在这里解决了问题（或者这是否是某种过早的优化/工程自行车脱落）。我真的无法想象用户会如何尝试分页两次。

你是对的，它是一个用于小应用程序的私有 API。我需要避免过早的和可能不必要的优化。