我的 Apollo GraphQL 旋转变压器如何“向前看”孩子，而不会失去传统旋转变压器结构的好处？

Question

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

特别是，这棵树的底部有些动态和无界。 总而言之，它看起来像这个简化的模式：

type Query {
  outer: OuterWrapper!
}

type OuterWrapper {
  inner: InnerWrapper!
}

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

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

目前，我们在树的顶部（ outer ）只有一个 Apollo 解析器，并使用graphql-fields库来处理info参数。 从本质上讲，我们是在“展望未来”——这是一种优化后端查询的流行模式。

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

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

1. graphql-fields响应不包括默认参数的值。 如果我写了一个适当的recurse解析器，如果它不在查询中，Apollo 会传入name的模式默认值。 我找到了一个要切换到的替代库（ graphql-parse-resolve-info ），但这不是 Apollo 解决方案，而且...
2. 如果我们抛出错误，则路径反映它发生在outer解析器中，而不是在树的更下方，它会更准确，对用户有用。

总而言之，我担心我会继续发现使用这种结构不太有效的东西，我正在考虑如何摆脱它。

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

我可以想象解析器构建查询并将其存储在context - outer解析器将创建查询，随后的解析器将根据他们认为合适的方式对其进行更改。 然后每个解析器可以返回一个正在等待 REST 响应的 promise。 但是，我看不到一个好方法来知道我的所有解析器何时被调用（并进行了更改），因此将 REST 请求发送到后端，或者让每个解析器知道它在查询结构中的位置（因此在 REST 响应中查找数据的位置）。

还有另一种我没有考虑过的方法吗？

Answer 1

GraphQL执行请求的自上而下的方式并不适合解析器构建查询，一旦所有解析器都运行，就会执行该查询。 部分原因是父字段的解析器必须在调用任何子字段解析器之前完成执行。 毕竟，需要使用父级解析的值来调用它们。

如果您对数据源有多个调用，则将它们拆分到不同的解析器可能是有意义的。 但是，如果您只需要对数据源进行一次调用，那么在顶层这样做并使用“前瞻”是最好的方法。 graphql-parse-resolve-info是一个很好的库来帮助解决这个问题。

对您现在所做的唯一改进可能是将用于将 REST 响应转换为某些非根字段的解析器的大部分逻辑。 通过这种方式，您可以在执行通过查询的每个“级别”时逐渐转换传递给每个解析器的parent值。