我一直在研究一些GraphQL实现,我理解的是GraphQL允许您以图形的形式遍历数据。
这意味着你会得到一张图书列表,这是一个休息电话。这些书可能有作者的名字。
当用户想要更多关于作者的信息时,他这样说,然后再调用REST来获取更多关于作者的详细信息。
类似地,图书列表可能有一个名为Publisher的字段,等等。因此,您在这里获取数据,就好像要将Book的一个节点连接到Author或Publisher的节点一样。
但是,我看到了一些实现,其中两个rest调用的数据使用for循环组合在UI中。例如,调用图书的REST,然后调用编写这些书籍的作者的REST。运行for嵌套的for-循环(n^2复杂性),在一个单一摘要视图中组合结果并显示书籍和作者的信息。
这是一个可以接受的实践,还是打破了GraphQL不应该做的一些核心概念?
发布于 2018-10-21 01:35:21
我不确定这样做是“打破了一些核心概念”,但以这种方式“预先加载”所有对REST端点的调用有一个潜在的缺点。GraphQL允许您为每个字段定义一个解析器,该解析器确定字段返回的值。在“子”字段之前解析“父”字段,并将“父”的值传递给每个“子”的解析器。
假设您有这样一个模式:
type Query {
book(id: ID): Book
}
type Book {
title: String
author: Author
publisher: Publisher
}在这里,book字段将解析为表示一本书的对象,该对象将被传递给title、author和publisher的解析器。
如果没有为特定字段提供解析器,则默认行为是在父对象上查找与该字段名称相同的属性并返回该属性。因此,您的book解析器可以从某个REST端点(3个调用总数)获取图书、作者和发布者,并返回合并的结果。或者,您可以只获取书籍,并让author字段解析器获取作者,publisher字段解析器获取发布服务器。
--它们的关键是,只有在请求该字段时才调用解析器。,这两种方法的不同之处在于,您可以查询book并只请求标题。
query SomeQuery {
book(id: 1) {
title
}
}在这个场景中,如果您前面加载了所有API调用,那么您将不必要地对REST端点进行两个额外的调用(对于作者和发布者)。
当然,如果您有一个返回一系列书籍的字段,您可能不希望通过为每一本所请求的书获取作者来敲击REST端点,因此在这种情况下,在根查询中同时获取图书和作者可能是有意义的。
这里没有一个正确的答案,因为两者都可能有取舍。这是一个如何设计模式、如何使用它以及您可以接受哪些成本的问题。
https://stackoverflow.com/questions/52909417
复制相似问题