我的Apollo GraphQL解析器如何在不失去传统解析器结构好处的情况下向孩子们“前瞻”？]

Question

我正在研究REST服务前的GraphQL API。 REST服务是具有许多复杂参数的单个端点-而不是将所有参数都放在单个GraphQL字段中，我们从逻辑上将其分解为GraphQL字段和类型的树。

尤其是，这棵树的底部有些动态且不受限制。总而言之，它看起来像这样的简化模式：

type Query {
  outer: OuterWrapper!
}

type OuterWrapper {
  inner: InnerWrapper!
}

type InnerWrapper {
  recurse(name: String = ""): RecursiveType!
}

type RecursiveType {
  recurse(name: String = ""): [RecursiveType!]!
  name: String!
}

[目前，我们在树的顶部只有一个Apollo解析器（outer），并使用graphql-fields库处理graphql-fields参数。从本质上讲，我们在“展望”子级-一个infopopularpattern to后端查询。 

这对我们来说效果很好-我们将子字段和参数映射到单个REST请求中，然后将响应映射回到正确的结构中。

但是，它确实有两个限制：

optimise响应不包括默认参数的值。如果我编写了正确的graphql-fields解析程序，则Apollo会为recurse传递模式默认值（如果不在查询中）。我找到了要切换到的替代库（name），但这不是Apollo解决方案，并且...
1. 如果抛出错误，则路径反映出它是在graphql-parse-resolve-info解析器中发生的，而不是沿树走得更远，因为它将更加准确，并且对用户有用。
2. 总的来说，我担心我将继续寻找使用这种结构无法正常工作的事物，并且我正在考虑如何摆脱这种结构。

有没有一种方法可以使用传统/完全指定的解析器结构增量构建单个后端REST请求？

我可以想象，解析器将构建查询，并将其存储在graphql-parse-resolve-info中-outer解析器将创建查询，随后的解析器将根据需要更改它。然后，每个解析器都可以返回一个正在等待REST响应的Promise。但是，我看不出有什么好方法可以知道何时调用了所有解析程序（并进行了更改），从而将REST请求激发到后端，或者让每个解析程序知道它在查询结构中的位置。 （以及因此在REST响应中查找数据的位置）。

我还没有考虑其他方法吗？

我正在研究REST服务前的GraphQL API。该REST服务是具有许多复杂参数的单个端点-而不是将所有参数都放在一个GraphQL上...

Answer 1

GraphQL的context并没有真正让解析器建立一个查询，该查询将在所有解析器运行后立即执行。部分原因是，父字段的解析器必须在调用任何子字段解析器之前完成执行。毕竟，它们需要使用父级解析为的值来调用。