不推薦使用 GraphQL 的理由

GraphQL Facebook 發佈於 2015，是一個 API 設計理念，主要以 “A query language for your API” 為出發點，並且有以下重點：

在開始前，先強調

Facebook 將 GraphQL 與 REST 做優缺點比較，而不是 RESTful```

擷取官方原文：While typical REST APIs require loading from multiple URLs, GraphQL APIs get all the data your app needs in a single request.

多數 GraphQL 文章會強調解決 REST 一些棘手問題，其中主要都在強調"減少請求"，而REST 則是會增加請求。

其實，這講得沒錯，但沒有人會使用 REST 原則來開發，多數人採用的都是 RESTful。

REST 是一個設計風格，全名為 Representational State Transfer (表現層狀態轉換)是在 2000 年，由 Roy Thomas Fielding 所提出來的一種軟體架構風格，用於定義資源及管理資源。

RESTful 則是基於 REST 的一種設計風格，而不是原則！

對於現今採用 GrapQL 的團隊，實際使用時，常見會結合 Restful API 來傳輸查詢內容，其實，在實作上並未增加太多便利性。

例如，當我們要查詢一個用戶資料時，使用 GraphQL 需要下這樣的語法

query("query{users(_id:" + req.params.userId + "){_id, name}}")

而 Restful 請求則相當簡單

http://urlpah/users/2

最基本上，在分頁查詢上，一般 API 常見透過 page 來切換分頁，

在 GraphQL 則需要透過 (first:n, offset:n) 來實現。

另外，關於 GraphQL 強調不需版本的概念，其實並非完全真實，在實作上也會容易寫出容易混淆的代碼。

最後，列出使用 GraphQL 有些缺點：

GraphQL 請求的方式一律使用 POST，需要適應 Restful 的架構要再做對應調整 (以 Apollo Client 為例，解決方式可透過 REST Route 作為 Gateway 來送出 GraphQL 查詢)
會將後端 API loading 轉移至前端
前端架構複雜度增加，維護的成本會同時提升，最終可能造成代碼混淆
還是會有發出多個 Request 的問題
仍須處理 API versioning 管控
容易建構出效能不佳的代碼，GraphQL的最大問題是它在單個端點上運行

最後，GraphQL 自 2015 推出至今仍無法引起廣大關注，以目前來說，多數為 Node.js 生態的團隊。

如果你目前是新創團隊，或者建構較為單純的系統架構時， GraphQL 可作為實踐的一選型參考。

若偏向於稍微中大型的架構，系統不會限制使用哪種語言，而是會依照屬性進行技術選型拆分，並且，會與不同團隊合作，例如 backend teams, DBA teams…。

如果你是一個代碼的偏好者，在需要遵循 GraphQL 理念來開發，也會遇到許多困難，需透過GraphQL和RESTful API 同時存在的情況才有辦法解決兼容問題。

最後強調，技術選型沒有絕對對錯，只要權衡評估後選擇適合自己的技術即可。

參考：