我正在尝试使用 GraphQL 实现批量查询接口。我可以毫无问题地获得同步工作的请求，但我不确定如何使结果异步。基本上，我希望能够启动查询并返回一个指向查询完成时结果最终会出现的位置的指针。我想这样做是因为查询有时可能需要很长时间。
在 REST 中，这是微不足道的。您返回一个 202 并返回一个 Location 标头，该标头指向客户端可以去哪里获取结果。 GraphQL 作为规范似乎没有这个概念；它似乎总是希望同步处理请求。
在 GraphQL 中做这样的事情有什么约定吗？我非常喜欢查询规范，但我宁愿在后端执行大型查询时不要让客户端 HTTP 连接打开几分钟。如果发生任何事情以终止该连接，则需要重试整个查询，即使结果本身是持久的。
【问题讨论】：
您尝试做的事情并不能以符合规范的方式轻松解决。 Apollo 引入了 @defer 指令的想法，它几乎可以满足您的需求，但它仍然是一个实验性功能。我相信现代接力is trying to do something similar。
这个想法实际上是相同的——客户端使用指令将字段或片段标记为可延迟。服务器解析请求，但保留延迟字段为空。然后它将一个或多个带有延迟数据的补丁发送到客户端。客户端能够将初始请求和补丁分别应用到其缓存中，像往常一样每次触发适当的 UI 更改。
【讨论】：
我最近正在研究一个类似的问题。我的用例是提交一份工作以创建报告并将结果提供给用户。创建报告需要几分钟，这使其成为异步操作。我创建了一个将作业提交到后端处理系统并返回作业 ID 的突变。然后我使用查询定期轮询jobs 字段，以了解作业的状态以及最终的结果。由于结果是一个文件，我返回一个指向不同端点的链接，可以在其中下载它（Github 使用类似的方法）。
对实际结果的轮询正在按预期工作，但我想这可能通过订阅更好地解决。
【讨论】：