GraphQL的深度和复杂性/成本限制-在哪里可以找到一个合理的起点？

问题描述

我的团队一直在构建一个GraphQL项目，当我开始对其进行测试时，我注意到我们能够创建您通常在深度设置示例中看到的类型的大型嵌套查询（帖子具有作者，而帖子具有一位作家 ...）。该项目还具有返回大量企业数据的潜力（请考虑一个员工列表以及每个员工附带的所有数据）。

考虑到这两点，我们知道我们需要设置一些深度，复杂度以及可能的最大响应时间限制，这样我们才不会有坏的参与者（或坏的工程师）使服务器崩溃。我真的找不到关于应该从哪里开始确保应用程序性能的任何信息，但仍然在前端开发人员如何查询端点方面提供了相当多的灵活性。我不知道我们是否应该从深度7，复杂度30，超时3秒开始，然后尝试从那里向上/向下缩放，或者是否有一种很好的方法来计算对于应用程序来说可能很好的方法。任何意见将不胜感激。 谢谢！

解决方法

不久前我将这张图片保存在我的磁盘中，我发现它很好地展示了复杂性。

我认为很难设置一个适用于所有查询的数字，正如您在图像中看到的，如果您有一些嵌套对象或子解析器，复杂性会呈指数级增长。

我有几个建议：

• 如果你的客户端没有直接调用 graphql 服务器，你 可以使用该中间件将查询拆分为更小的块和 合并为一个并发回客户端。
• 您认为可以超过限制并降低限制的白名单查询 其他查询