【问题标题】:Graphql schema design best practiceGraphql 架构设计最佳实践
【发布时间】:2020-07-13 11:06:17
【问题描述】:

我有一个问题:

假设我有这样的产品类型

type Option {
  id: Int!
  value: String!
}

type Product{
  id: Int!
  name: String!
  price: Float!
  options: Option
}

如果我有这样的模式,每次我需要产品选项(我从请求中获得 productID)时,我都需要查询整个产品(带有 id、名称、价格),我将对数据库进行 2 个 Mysql 查询(1 获取产品,1 获取产品选项)。

我是否应该在这样的 Query 对象中有一个额外的独立字段来获取基于 productID 的产品选项?如果我需要像上面那样保留嵌套模式,有没有办法在不执行它的父(产品)解析器的情况下获得产品选项?

product_options(productId: Int!) : Option

谢谢

【问题讨论】:

    标签: graphql graphql-schema


    【解决方案1】:

    我认为这更像是一个数据关系问题,但尽管如此......

    IMO SQL 数据库中Product Options 的表(如果还没有)应该有一个列,该列是它所属/关联的Product 的外键。这样做可以让您轻松拥有嵌套的 GraphQL 类型和字段级解析器。

    完成后,您将不需要单独查询选项结构,您的 Product.options 字段级解析器只需查询即可:

    {
      product(id: 123) {
        options {
          value
        }
      }
    }
    

    您可以在代码中使用已获取的Product.id 字段来对其选项行运行字段级查询。

    【讨论】:

    • 感谢您的回答。但是如果你这样做,产品类型的解析器将被执行并创建一个对“产品”表的查询,当再有一个查询到“选项”表时,对吗?当我只想要选项而不是产品名称、价格时,这就是我想要避免的事情
    • @NHT 是的,理论上是这样,如果你完全想避免这种情况,那么这可能不是正确的方法。需要记住的是,虽然有一些设计模式被很好地采用(如Connection 模式),但您最终应该根据消费者的需求设计您的 API/模式
    • 感谢您的建议。
    • 嗨@m_callens 如果我保持这样的嵌套模式,有什么方法可以在不执行其父(产品)解析器的情况下获得产品选项?
    • @NHT 我能想到的唯一方法是将其他 Product 属性包装在 data 对象或其他东西中,所以 type Product 只有两个字段:data 和 @ 987654331@ 每个都有其他字段级解析器。这样,如果您查询product.data,则只查询核心产品字段,如果您查询product.options,则仅执行选项查询
    猜你喜欢
    • 2018-03-08
    • 2019-06-07
    • 1970-01-01
    • 2013-01-04
    • 2015-07-13
    • 2020-06-12
    • 2010-11-17
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多