這一篇簡單介紹一下GraphQL的概念及可以幫助我們解決什麼問題，並有什麼優勢

GraphQL：既是一種用於 API 的查詢語言也是一個滿足你資料查詢的執行時。 GraphQL 對你的 API 中的資料提供了一套易於理解的完整描述，使得客戶端能夠準確地獲得它需要的資料，而且沒有任何冗餘，也讓 API 更容易地隨著時間推移而演進，還能用於構建強大的開發者工具。
以上內容摘抄自官網。簡單說一下我的理解：可以說是Web服務的一種新的架構和規範，並且在FaceBook、gitHub、Twitter中均已使用。對比現在業務使用的Restful來說，有下列優勢：

• 單endpoint：一個請求獲取所有資料，解決RestAPI多個請求獲取資源的問題
• 清晰的資料模型，欄位強型別
• 按需獲取，減少網路請求，無冗餘
• API迭代順暢，無須版本化
• 協議而非儲存，對服務端資料進行組裝過濾

Rest比較

• 資料獲取：Rest缺乏擴充套件性，GraphQL獲取時，payload可以擴充套件，按需獲取
• API呼叫：Rest有多個endpoint，GraphQL在大多數情況下只有1個endpoint，只是body內容不同
• 複雜請求：Rest需要多次，GraphQL一次呼叫，減少網路開銷
• 返回處理：Rest有多種httpCode及Status，GraphQL只有200響應，錯誤內容需要在結果集中特殊獲取
• 版本號：Rest使用V1、V2，GraphQL可根據Schema自行擴充套件

可以看出，GraphQL對前端開發來說幫助巨大，減少了很多工作量。但為了配合使用，伺服器端需要怎麼協同，並有什麼好處呢？簡單看了幾個例子後發現，後端如果使用Graphql重構，就相當於服務層做了一層使用GraphQL引擎對已獲取的結果資料再做一次包裝。

自己的理解

• 可以預見，服務端在改造時，資料獲取層不會有太大的工作量，但由於只有一個endpoint，在業務邏輯層可能需要拼接原來多個介面返回的資料。比如個人主頁的訪問，原本需要a請求返回個人資訊，b請求返回朋友關係。在GraphQL的架構中，需要將a、b請求的資料在服務端合併，並使用GaphQL引擎構建執行時，對外提供介面c。這樣就意味著c介面需要承擔a、b兩個請求的查詢量，效能方面是否會有瓶頸？
• 其次，對於資料模型的定義務必精確，哪些欄位可以被查詢，哪些需要有請求引數，還有分頁等都需要考慮。
• 對於資料校驗、使用者許可權及資料安全性來說解決方案也比較模糊。因為整體的請求返回需要GraphQL引擎來處理，所以原本一些過濾器攔截器的方案可能被替代，需要業務層來完整處理應對。
• GraphQL-Java的文件較少，而且官網上的一些demo也無法執行，前期調研成本較大

總結

通過對官網的瀏覽，對後端來說，並沒有覺得有什麼很明顯的優勢。但對前端或者整個專案來說，提升還是挺明顯的，具體效果等實際應用了以後再看吧。後面幾章會介紹一下GraphQL的語法，並使用GraphQL-java做一些伺服器端的Demo及資料模型的建立。

參考

Graphsql中文官網地址
Graphsql-Java文件
Graphsql-Java官方文件翻譯