踩坑：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  
? ? }  
? }  
}