踩坑：6年后为何不用GraphQL了？

GraphQL 是一项令人难以置信的技术，自从我在 2018 年首次开始将其投入生产以来，它就吸引了很多人的注意力。
在一大堆无类型的 JSON REST API 上构建了许多 React SPA 之后，我发现 GraphQL 是一股清新的空气。

然而，随着时间的推移，我有机会部署到更需要关注安全性、性能和可维护性等非功能性要求的环境中，我的观点发生了变化。在本文中，我想向您介绍为什么今天我不向大多数人推荐 GraphQL，以及我认为更好的替代方案。

安全性
从 GraphQL 诞生之初，很明显将查询语言暴露给不受信任的客户端会增加应用程序的攻击面。然而，需要考虑的攻击种类比我想象的还要多，缓解这些攻击是一项相当大的负担。以下是我多年来遇到的最糟糕的情况……

1、授权
这是 GraphQL 最广为人知的风险。
如果您向所有客户端公开一个完全自文档化的查询 API，您最好确保每个字段都针对当前用户进行了适当的授权，以适应正在获取该字段的上下文。最初授权对象似乎足够了，但这很快就会变得不够。


query {  
  user(id: 321) {  
    handle # 我可以查看用户的公开信息  
    email # 我不应该因为可以查看用户名，就能看到他们的个人信息。  
  }  
  user(id: 123) {  
    blockedUsers {  
      # 有时我甚至不应该看到他们的公开信息，  
      # 因为上下文很重要！  
      handle  
    }  
  }  
}

人们不禁要问，GraphQL 对“访问控制失效”升至OWASP 前 10 名中的第 1 名负有多大责任。

这里的一个缓解措施是通过与GraphQL 库的授权框架集成，使 API 默认安全。每个返回的对象和/或解析的字段，都会调用您的授权系统来确认当前用户是否具有访问权限。

将此与 REST 世界进行比较，一般来说，您会授权每个端点，这是一项小得多的任务。

2、速率限制
我刚刚针对一个非常受欢迎的网站的 GraphQL API 浏览器测试了此攻击：


query {  
  \_\_schema{  
    types{  
      \_\_typename  
      interfaces {  
        possibleTypes {  
          interfaces {  
            possibleTypes {  
              name  
            }  
          }  
        }  
      }  
    }  
  }  
}

并在 10 秒后获得了 500 响应。我刚刚耗费了某人 10 秒的 CPU 时间来运行这个（删除空格）128 字节查询，而且它甚至不需要我登录。

这种攻击的常见缓解方法：

估算解析数据结构schema中每个字段的复杂度，放弃超过某个最大复杂度值的查询
捕捉运行查询的实际复杂度，并将其从按一定间隔重置的积分桶中提取出来

要正确计算复杂度是一件很复杂的事情。如果在执行前不知道返回列表字段的长度，计算就会变得特别棘手。您可以对这些字段的复杂性进行假设，但如果假设错误，最终可能会限制有效查询的速率或不限制无效查询的速率。

更糟糕的是，构成结构schema的图形通常包含循环。比方说，您运行一个博客，其中的每篇文章都有多个标签，您可以从中看到相关的文章。


type Article {  
  title: String  
  tags: \[Tag\]  
}  
type Tag {  
  name: String  
  relatedTags: \[Tag\]  
}

在估算 Tag.relatedTags 的复杂度时，您可能会假设一篇文章永远不会有超过 5 个标签，因此将该字段的复杂度设为 5（或 5 * 其子字段的复杂度）。这里的问题是 Article.relatedTags 可以是它自己的子标签，因此您的估计不准确性会以指数形式增加。计算公式为 N^5 * 1：


query {  
  tag(name: "security") {  
    relatedTags {  
      relatedTags {  
        relatedTags {  
          relatedTags {  
            relatedTags { name }  
          }  
        }  
      }  
    }  
  }  
}

您预计复杂度为 5^5 = 3,125。如果攻击者能找到一篇有 10 个标签的文章，他们就能触发一个 "真实 "复杂度为 10^5 = 100_000 的查询，比预计的复杂度高 20 倍。

部分缓解措施是防止深度嵌套查询。不过，上面的示例表明，这并不是真正的防御措施，因为这并不是一个异常深的查询。GraphQL Ruby 的默认最大深度是 13，而这只是 7。

与 REST 端点的速率限制相比，后者的响应时间通常相当。在这种情况下，你所需要的只是一个桶式速率限制器，防止用户在所有端点上的请求超过每分钟 200 次。如果确实有速度较慢的端点（如 CSV 报告或 PDF 生成器），可以为其定义更严格的速率限制。使用某些 HTTP 中间件，这一点非常简单：


Rack::Attack.throttle('API v1', limit: 200, period: 60) do |req|  
  if req.path =~ '/api/v1/'  
    req.env\['rack.session'\]\['session\_id'\]  
  end  
end

3、查询解析
在执行查询之前，首先要对其进行解析。我们曾经收到过一份笔试报告，证明有可能伪造出一个无效的查询字符串，导致服务器宕机。例如

query {  
  \_\_typename @a @b @c @d @e ... # imagine 1k+ more of these  
}

这是一个语法上有效的查询，但对我们的结构schema来说是无效的。符合规范的服务器会对其进行解析，并开始生成包含数千个错误的错误响应，我们发现这些错误所消耗的内存是查询字符串本身的 2,000 倍。由于这种内存放大效应，仅仅限制有效负载的大小是不够的，因为你会遇到比最小的危险恶意查询还要大的有效查询。

如果你的服务器提供了一个概念，即在放弃解析之前最多会出现多少次错误，那么这种情况就可以得到缓解。如果没有，您就必须自行解决。目前还没有与这种严重程度相当的 REST 攻击。

性能
说到 GraphQL 的性能，人们经常会说它与 HTTP 缓存不兼容。就我个人而言，这并不是一个问题。对于 SaaS 应用程序来说，数据通常是高度用户特定的，提供陈旧的数据是不可接受的，所以我没有发现自己错过了响应缓存（或缓存失效导致的错误......）。

我发现自己在处理的主要性能问题是...

1、数据获取和 N+1 问题
我认为这个问题如今已被广泛理解。简而言之：如果字段解析器命中一个外部数据源（如 DB 或 HTTP API），并且它嵌套在一个包含 N 个项的列表中，那么它将执行这些调用 N 次。

这并不是 GraphQL 独有的问题，实际上，严格的 GraphQL 解析算法已经让大多数库共享了一种通用的解决方案：Dataloader 模式。

但 GraphQL 的独特之处在于，由于它是一种查询语言，当客户端修改查询时，如果后端没有任何变化，这就会成为一个问题。因此，我发现最终不得不在各处防御性地引入 Dataloader 抽象，以防将来客户端最终在列表上下文中获取字段。这需要编写和维护大量的模板。

与此同时，在 REST 中，我们通常可以将嵌套的 N+1 查询上传到控制器，我认为这种模式更容易理解：


class BlogsController < ApplicationController  
  def index  
    @latest\_blogs = Blog.limit(25).includes(:author, :tags)  
    render json: BlogSerializer.render(@latest\_blogs)  
  end  
  
  def show  
    # No prefetching necessary here since N=1  
    @blog = Blog.find(params\[:id\])  
    render json: BlogSerializer.render(@blog)  
  end

end

2、授权和 N+1 问题
还有更多的 N+1！

如果你按照之前的建议与库包的授权框架集成，那么你现在就有了一个全新的 N+1 问题需要处理。让我们继续前面的 X API 示例：


class UserType < GraphQL::BaseObject  
  field :handle, String  
  field :birthday, authorize\_with: :view\_pii  
end  
  
class UserPolicy < ApplicationPolicy  
  def view\_pii?  
    # 哦，不，我点击了数据库来获取用户的好友信息  
    user.friends\_with?(record)  
  end  
end  
query {  
  me {  
    friends { # returns N Users  
      handle  
      birthday # runs UserPolicy[**view**](/query/searchAction.shtml?query=view)\_pii? N times  
    }  
  }  
}