GraphQL 作為一種 API 查詢語句，於2015年被 Facebook 推出，主要是為了替代傳統的 REST 模式，那麼對於 GraphQL 和 REST 究竟有哪些異同點呢？我們可以通過下面的例子進行理解。
按照 REST 的設計標準來看，所有的訪問都是基於對資源的訪問（增刪查改）。如果對系統中 users資源的訪問，REST 可能通過下面的方式訪問：
Request:
Response:
對於同樣的請求如果用 GraphQL 來訪問，過程如下：
Request:
Body:
Response:
關於 GraphQL 更詳細的用法，我們可以通過查看文檔以及其他文章更加詳細的去了解。相比於 REST 風格，GraphQL 具有如下特性：
1. 定義數據模型：按需獲取
GraphQL 在服務器實現端，需要定義不同的數據模型。前端的所有訪問，最終都是通過 GraphQL 後端定義的數據模型來進行映射和解析。並且這種基於模型的定義，能夠做到按需索取。比如對上文 /users資源的獲取，如果客戶端只關心 user.id, user.name信息。那麼在客戶端調用的時候，query中只需要傳入 users {id \n name}即可。後臺定義模型，客戶端只需要獲取自己關心的數據即可。
2. 數據分層
查詢一組users數據，可能需要獲取 user.friends, user.friends.addr等信息，所以針對 users 的本次查詢，實際上分別涉及到對 user, frind, addr三類數據。GraphQL 對分層數據的查詢，大大減少了客戶端請求次數。因為在 REST 模式下，可能意味著每次獲取 user數據之後，需要再次發送 API 去請求 friends 接口。而 GraphQL 通過數據分層，能夠讓客戶端通過一個 API獲取所有需要的數據。這也就是 GraphQL（圖查詢語句 Graph Query Language）名稱的由來。
3. 強類型
GraphQL 的類型系統定義了包括 Int, Float, String, Boolean, ID, Object, List, Non-Null 等數據類型。所以在開發過程中，利用強大的強類型檢查，能夠大大節省開發的時間，同時也很方便前後端進行調試。
4. 協議而非存儲
GraphQL 本身並不直接提供後端存儲的能力，它不綁定任何的數據庫或者存儲引擎。它利用已有的代碼和技術進行數據源的管理。比如作為在 BFF 層使用 GraphQL, 這一層的 BFF 並不需要任何的數據庫或者存儲媒介。GraphQL 只是解析客戶端請求，知道客戶端的“意圖”之後，再通過對微服務API的訪問獲取到數據，對數據進行一系列的組裝或者過濾。
5. 無須版本化
GraphQL 服務端能夠通過添加 deprecationReason，自動將某個字段標註為棄用狀態。並且基於 GraphQL 高度的可擴展性，如果不需要某個數據，那麼只需要使用新的字段或者結構即可，老的棄用字段給老的客戶端提供服務，所有新的客戶端使用新的字段獲取相關信息。並且考慮到所有的 graphql 請求，都是按照 POST /graphql發送請求，所以在 GraphQL 中是無須進行版本化的。
GraphQL 和 REST
對於 GraphQL 和 REST 之間的對比，主要有如下不同：
1. 數據獲取：REST 缺乏可擴展性， GraphQL 能夠按需獲取。GraphQL API 調用時，payload 是可以擴展的;
2. API 調用：REST 針對每種資源的操作都是一個 endpoint, GraphQL 只需要一個 endpoint( /graphql), 只是 post body 不一樣;
3. 複雜數據請求：REST 對於嵌套的複雜數據需要多次調用，GraphQL 一次調用, 減少網絡開銷；
4. 錯誤碼處理：REST 能夠精確返回HTTP錯誤碼，GraphQL 統一返回200，對錯誤信息進行包裝；
5. 版本號：REST通過 v1/v2 實現，GraphQL 通過 Schema 擴展實現；
微服務 + GraphQL + BFF 實踐
在微服務下基於 GraphQL 構建 BFF，我們在項目中已經開始了相關的實踐。在我們項目對應的業務場景下，微服務後臺有近 10 個微服務，客戶端包括針對不同角色的4個 App 以及一個 Web 端。對於每種類型的 App，都有一個 BFF 與之對應。每種 BFF 只服務於這個 App。BFF 解析到客戶端請求之後，會通過 BFF 端的服務發現，去對應的微服務後臺通過 CQRS 的方式進行數據查詢或修改。
1. BFF 端技術棧
我們使用 GraphQL-express 框架構建項目的 BFF 端，然後通過 Docker 進行部署。BFF 和微服務後臺之間，還是通過 registrator 和 Consul 進行服務註冊和發現。
在 BFF 的路由設置中，對於客戶端的處理，主要有 /graphql和 /api/${serviceName}兩部分。/graphql處理的是所有 GraphQL 查詢請求，同時我們在 BFF 端增加了/api/${serviceName}進行 API 透傳，對於一些沒有必要進行 GraphQL 封裝的請求，可以直接通過透傳訪問到相關的微服務中。
2. 整體技術架構
整體來看，我們的前後端架構圖如下，三個 App 客戶端分別使用 GraphQL 的形式請求對應的 BFF。BFF 層再通過 Consul 服務發現和後端通信。
關於系統中的鑑權問題
用戶登錄後，App 直接訪問 KeyCloak 服務獲取到 id_token，然後通過 id_token透傳訪問 auth-api服務獲取到 access_token, access_token 以 JWT (Json Web Token) 的形式放置到後續 http 請求的頭信息中。
在我們這個系統中 BFF 層並不做鑑權服務，所有的鑑權過程全部由各自的微服務模塊負責。BFF 只提供中轉的功能。BFF 是否需要集成鑑權認證，主要看各系統自己的設計，並不是一個標準的實踐。
3. GraphQL + BFF 實踐
通過如下幾個方面，可以思考基於 GraphQL 的 BFF 的一些更好的特質：
GraphQL 和 BFF 對業務點的關注
從業務上來看，PM App（使用者：物業經理）關注的是property，物業經理管理著一批房屋，所以需要知道所有房屋概況，對於每個房屋需要知道有沒有對應的維修申請。所以 PM App BFF 在定義數據結構是，maintemamceRequests是property的子屬性。
同樣類似的數據，Supplier App（使用者：房屋維修供應商）關注的是 maintenanceRequest（維修工單），所以在 Supplier App 獲取的數據裡，我們的主體是maintenanceRequest。維修供應商關注的是 workOrder.maintenanceRequest。
所以不同的客戶端，因為存在著不同的使用場景，所以對於同樣的數據卻有著不同的關注點。BFF is pary of Application。從這個角度來看，BFF 中定義的數據結構，就是客戶端所真正關心的。BFF 就是為客戶端而生，是客戶端的一部分。需要說明的是，對於“業務的關注”並不是說，BFF會處理所有的業務邏輯，業務邏輯還是應該由微服務關心，BFF 關注的是客戶端需要什麼。
GraphQL 對版本化的支持
假設 BFF 端已經發布到生產環境，提供了 inspection相關的 tenants和 landlords的查詢。現在需要將圖一的結構變更為圖二的結構，但是為了不影響老用戶的 API 訪問，這時候我們的 BFF API 必須進行兼容。如果在 REST 中，可能會增加api/v2/inspections進行 API 升級。但是在 BFF 中，為了向前兼容，我們可以使用圖三的結構。這時候老的 APP 使用黃色區域的數據結構，而新的 APP 則使用藍色區域定義的結構。
GraphQL Mutation 與 CQRS
如果你詳細閱讀了 GraphQL 的文檔，可以發現 GraphQL 對 query和 mutation進行了分離。所有的查詢應該使用 query { ...}，相應的 mutaition 需要使用mutation { ... }。雖然看起來像是一個convention，但是 GraphQL 的這種設計和後端 API 的 讀寫職責分離（Command Query Responsibility Segregation）不謀而合。而實際上我們使用的時候也遵從這個規範。所以的 mutation 都會調用後臺的 API，而後端的 API 對於資源的修改也是通過 SpringBoot EventListener 實現的 CQRS 模式。
如何做好測試
在引入了 BFF 的項目，我們的測試仍然使用金字塔原理，只是在客戶端和後臺之間，需要添加對 BFF 的測試。
Client 的 integration-test 關心的是 App 訪問 BFF 的連通性，App 中所有訪問 BFF 的請求都需要進行測試；
BFF 的 integration-test 測試的是 BFF 到微服務 API 的連通性，BFF 中依賴的所有 API 都應該有集成測試的保障；
API 的 integration-test 關注的是這個服務對外暴露的所有 API，通常測試所有的 Controller 中的 API；
結語
微服務下基於 GraphQL 構建 BFF 並不是銀彈，也並不一定適合所有的項目，比如當你使用 GraphQL 之後，你可能得面臨多次查詢性能問題等，但這不妨礙它成為一個不錯的嘗試。你也的確看到 Facebook 早已經使用 GraphQL，而且 Github 也開放了 GraphQL 的API。而 BFF， 其實很多團隊也都已經在實踐了，在微服務下等特殊場景下，GraphQL + BFF 也許可以給你的項目帶來驚喜。
【注】部分圖片來自網絡
https://martinfowler.com/articles/microservices.html
https://www.thoughtworks.com/insights/blog/bff-soundcloud
http://philcalcado.com/2015/09/18/thebackendforfrontendpattern_bff.html
http://samnewman.io/patterns/architectural/bff
https://medium.com/netflix-techblog/embracing-the-differences-inside-the-netflix-api-redesign-15fd8b3dc49d
文／ThoughtWorks龔銘
原文鏈接：https://insights.thoughtworks.cn/use-graphql-build-bff-in-microservices/
閱讀更多 ThoughtWorks 的文章
