[譯] 從 Reddit 討論中看到的 GraphQL 現狀

• 原文地址：The state of GraphQL by Reddit
• 原文做者：Robert Matyszewski
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：TiaossuP
• 校對者：yangxy81118

從 Reddit 討論中看到的 GraphQL 現狀

一提到 GraphQL，就會看到各種炒做文章以及將它與 REST 進行比較的爭論。GraphQL 如今處於全球流行、全面使用的早期階段，沒有人確切知道它會在哪裏在止步。經過在互聯網上的調研，我發現了許多對這項新技術的安利文章。這只是對第一印象的炒做嗎？

我研究了 Reddit 上關於 GraphQL 的評論，並挑選了其中一些最受歡迎的內容。本文旨在以透明、客觀的態度來討論這個主題，因此對於每一個派別的不一樣觀點，我都挑選了一些用戶的探討與爭論的內容。下面的每一個評論引用都有一個指向其做者的連接，同時（）中的爲該評論的點贊 （譯註：原文爲 upvote） 數量。不過要注意，我撰寫與發表本文之後，點贊數字可能會發生變化。

議程

• 總體情況
• React & Apollo 情況
• 大公司 & GraphQL
• 緩存
• 請求數據
• 總結

總體情況

從總體出發，我選擇了兩個實踐例子。首先，SwiftOneSpeaks 顯示了前端開發人員的視角和潛在的市場改進。其次，Scruffles360 展現了團隊如何適應 graphql 以及他們使用具體工具的策略趨勢。稍後您會發現更多他的評論。第二個評論是本文中選擇的贊最少的評論。

SwiftOneSpeaks（23）說：

當我與後端開發團隊合做時，他們更傾向於提供新的查詢來知足個人需求，由於這不會影響他們必須支持的現有查詢。（也就是說，我不知道隨着時間的推移，這個查詢的擴展性會怎樣）。GraphQL 還減小了我必須從新解析爲可用（知足個人須要）的數據結構的糟糕響應的數量。（例如，我獲得了 3 個數組，我必須將它們關聯起來並壓縮到一組對象中。儘管後端仍然須要有一些工做要作，但使用 GraphQL，我能夠有更豐富的能力來要求數據格式。）

Scruffles360（8）描述了他在 GraphQL 領域內看到的三個發展方向：

• 巨石應用：這就是阿波羅如今所推進的。每家公司都有一個且只有一個 api endpoint 和 schema 代理其餘全部東西（principledgraphql.com/）。我完徹底全不一樣意這個思路，但不會在這裏重複個人論點（若是想了解的話，您能夠挖掘個人評論歷史）
• 數據庫 api：出於一些奇怪的緣由，人們已經開始向數據庫添加插件，這些插件能夠經過 graphql 直接訪問數據庫。因爲不少緣由，Graphql 很是棒，可是它還不能與原生數據庫查詢語言相媲美。更重要的是，這去掉了您的業務層，使調用者能夠直接訪問您的 store。除了一個微服務應用，其他任何人都不該擁有訪問store的權限 —— 其餘人應該經過您的 api 調用服務。
• 中間路線：經典的 API 作法，每一個應用程序都有本身的 API（在本例中爲 GraphQL）。它可能將業務邏輯或代理隔離到微服務（經過 rest 或經過 schema stitching 到另外一個 Graphql 架構）。這是咱們走的路，目前爲止還沒讓我後悔。

React & Apollo 情況

React 和 Apollo 的組合得到了不少關注。此外 Wronglyzorro 和 Livelierepeat 討論爲何後端開發可能不喜歡 GraphQL。一位更有經驗的開發人員的迴應得到了更多的贊。另外，我選擇了一個更長但很是詳細的評論。

Wronglyzorro（12）：

咱們在網絡應用程序上嚴格使用 react + apollo。咱們也強迫移動客戶端也使用它。雖然聽起來有些荒誕，但這確實是大趨勢。後端開發人員固然討厭它，由於他們習慣了本身原有的方式，不喜歡改變。然而，在咱們過去一年中出現的故障中，從沒有 GraphQL 致使的，崩潰的老是遺留的後端服務。

Livelierepeat（40）回覆：

後端開發人員固然討厭它，由於他們習慣了本身原有的方式，不喜歡改變。

您可能想要了解個人觀點，我曾經是一個年輕的開發人員，使用全部最新的工具，並嘲笑那些「適應不了」的人。我瞭解到，一般有比「人們討厭改變」更有趣的緣由。好比 GraphQL 的抽象是否太過複雜？他們抗拒工做量的增長，可究竟增長了什麼？

有時，全部的工具都是最新的，反而可能不能讓這些工具的效用獲得最大凸顯。更關鍵的仍是在於理解代碼和參與開發的人。

Capaj （11）的詳細總結：

咱們從五月開始在生產環境中使用 GraphQL。咱們是一個全棧團隊，因此咱們不須要仰仗合做的後端團隊的憐憫。說服每一個人並不容易，不過 GQL 內置了一個示例，每一個人都認爲它看起來比 REST 更好。Graphiql 對此有很大幫助。

這挺好的。咱們在後端使用 apollo 引擎，我很是喜歡在生產環境中使用指標捕捉 API 錯誤。咱們使用 decapi 來裝飾咱們的 objection.js DB Model。咱們在單獨的地方定義 model，而後不須要作什麼就能夠自動生成 GQL。

在前端，咱們使用 apollo-client，但到目前爲止咱們尚未使用緩存。咱們的前端重點是擺脫以前的 angular.js 代碼，因此咱們尚未時間去試驗前端緩存。

我還沒有使用 apollo 進行客戶端狀態管理，由於到目前爲止我聽到的全部反饋都代表它還沒有準備好面對生產環境。另外，我不得不說它看起來很囉嗦，寫起來也很囉嗦。相反，我但願我能夠擴展 github.com/mhaagens/gq… 並將其用於咱們的狀態管理需求。MST 使用 typescript 表現的很好。若是咱們能夠在編輯 GQL 查詢時動態地從查詢中生成 MST 模型，咱們能夠大大提升咱們的工做效率。

緩存

我已經從 SwiftOneSpeaks 和 Scruffles360 中看到了不少很棒的和高讚的評論，這些評論已經在上文提到了。如下是他們討論的緩存問題和潛在解決方案。

SwiftOneSpeaks (23) 寫道：

雖然您能夠將 GraphQL 配置爲以各類方式工做，但實際上它們始終是 POST 請求。這意味着全部依賴於 GET 冪等而 POST 不冪等這一約定的瀏覽器緩存、CDN 緩存、代理緩存在默認狀況下都將失效。一切都被視爲新請求。雖然您能夠在客戶端自行作一些更智能的緩存，但這實際上只是在解決您本身產生（指引入GraphQL）的問題。

Scruffles360 (11) 回覆：

阿波羅有一個解決方案 —— 「動態持久化查詢」，不過我尚未嘗試過。大體來講，客戶端將使用 GET 請求（將 query 哈希），若是失敗，則回退到 POST。接下來的 GET 調用將成功並應用到任何代理緩存。

請求數據

這些人還對數據提取提出了不一樣的觀點。在 graphql-vs-rest （譯文在此） 中，做者描述了一個具備多個做者的博客應用程序示例以及使用 GraphQL 與 REST 的可能性。

SwiftOneSpeaks (23) 說：

每一個人都強調「過分請求」問題 （譯註：原文爲 Over fetching，意指請求的數據中有不少您並不須要的字段。還有一個相似的概念：Under fetching，意指某個接口的返回數據不夠，部分字段缺失，致使還須要請求第二個接口，這兩種狀況的問題都在於浪費了沒必要要的網絡資源） 問題。我以爲這根本不是設計出糟糕服務的藉口（事實上問題在於 —— 若是開發者一直很菜，那麼他寫出來的 GraphQL 服務也不可能就忽然好用了）。這很容易解決，只須要在原有服務前面加一個服務就行 —— GraphQL 能夠勝任這項工做，但用別的東西也能夠。問題不在因而否過分請求，而是中央服務與解決緩存問題。

Scruffles360（12）回覆：

過分請求確實是一個問題。當您有數百個客戶端時，每一個客戶端都以不一樣的方式調用您的系統，則向 rest api 添加一個屬性就會致使極大的效率下降。許多人提出爲移動客戶端和 web 端提供不一樣的門面接口，但這樣擴展性不好。個人項目由數百個客戶端調用，每一個客戶端的請求方式與請求內容都有些許不一樣。

大公司 & GraphQL

每一個人都對 Facebook、Netflix 和 Coursera 等大公司以及他們對 GraphQL 的使用狀況感興趣。對於這篇 graphql-vs-rest 在 Reddit 中的評論中，咱們能夠找到兩個主要緣由做爲做者 - 狀態。提出的第一條評論是我發現的最受歡迎的評論。

• 在 2010 年初，移動用戶數量激增，出現了與低功耗設備和緩慢網絡相關的一些問題。REST 不是處理這些問題的最佳選擇；
• 隨着移動使用量的增長，運行客戶端應用程序的不一樣前端框架和平臺的數量也在增長。因爲 REST 不夠靈活，致使咱們更難開發出一個可以知足全部終端應用需求的單一 API。

Greulich（62）回覆這篇文章：

這離題太遠，沒有意義。構造請求的另外一種方法不會使這些請求所在的網絡更好或更差。 我認爲做者的描述的是 endpoint 而不是 API，由於任何 endpoint，不管有多少 endpoint，都只是 API 的一部分。假設是這樣，爲何咱們只須要一個 endpoint？

Scruffles360（16）回覆 Greulich：

文章中的前兩點措辭並很差，但仍然是正確的。REST API 能夠是通用、可複用的，也能夠是專門爲已知客戶端設計。在第一種狀況下，當您須要不斷再次調用系統以獲取更多數據時 （譯者注：即上面提到的 Under fetching）（尤爲是像10年前咱們在移動設備上那樣的高延遲網絡），將沒法得到良好的性能。若是您爲特定客戶端製做 API，則顯然會遇到可擴展性問題。

總結

在選擇正確的評論來總結 GraphQL 的狀態時，有不少話要說或選擇。直到今天關於 reddit 的最受歡迎的 submissions 是 facebook 或 netflix 的案例研究，但這些 submission 的評論並很少。這給了咱們以 reddit 對 GraphQL 的見解的一個很好的總結。想到各位開發者的平常生活後，我沒法忽略 Kdesign（36）寫下的內容：

GraphQL 讓您的工做更安全，這是確定的。

您必須花時間在前端和實際數據存儲之間的全部 N 多層中，尋找數據的位置。

Kollektiv（44）列出了不少GraphQL問題：

• 查詢限速和權限評估等很難實現。
• 類型和數據加載器的工做方式，若是不編寫完整的 module 就分組查詢，則難以有效的方式將查詢綁定到數據庫層。
• 驗證僅檢查類型，所以您仍須要某種 JSON schema 來執行其餘格式驗證。
• GraphQL 查詢只容許 left join，所以像 INNER JOIN 加過濾這種從新建立 SQL 就變得很棘手了。
• 來自像 Relay 這樣的框架強加的分頁（鏈接）仍是一團糟。

關於我對GraphQL的初步研究 SwiftOneSpeaks（24）寫道：

我認爲咱們看到了不少「GraphQL 很棒」報告主要是由於任何新服務都很棒 —— 隨着時間的推移，由於假設條件被違背 （譯註：假設條件的概念能夠參考淺談Architectural Assumption（軟件架構設計的假設條件））、需求變動和代碼變動，它們確定會變得逐漸笨拙。不過這並不意味着 GraphQL很差 —— 只是說意味着我不能過多地信任早期報告。

最後，我選擇了 Mando0975 （28）的觀點來總結這篇文章：

開發始終是爲工做挑選合適的工具。GraphQL 不是銀彈。REST 並無死，GraphQL 也不會殺掉它。

您的 GraphQL 體驗如何？

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。