What？

GraphQL 是一種類似於 SQL 的結構化查詢語言，由 facebook 於2012年創造，於2015年開源。SQL 在服務端定義，GraphQL 在客戶端定義，也就是說 GraphQL 將數據的操作控制權從後端轉移到了前端。

facebook 創造 GraphQL 的目的是取代以前用的 Restful API，這個方案之漂亮，連 jQuery 之父也忍不住嘖嘖稱嘆：

Why？

傳統的 Restful API 存在的主要問題是無法靈活、精準的匹配前端的數據需求。

　　首先，產品的需求經常變，於是前端需要的接口也經常變，比如遇到版本叠代，即便整個數據庫結構沒有任何變化，常常也需要重寫或新增很多接口。其次，前端存在不同的平臺，可能對同一類數據的請求，web 端和 app 端需要的字段是不一樣的。

　　後端的接口要做到與前端的需求一一匹配，會極大的增加後端的工作量，因此後端的基本原則是“為多個請求提供一個接口並集，而不是分別為每個請求單獨提供接口”，“有現成可用，就盡量不新增接口”，比如前端需要兩個接口 {1, 2}、{1, 3, 4}，後端只需提供一個接口 {1, 2, 3, 4}。

　　於是前端對數據的需求和後端提供的接口常常無法精準匹配。前端總會遇到這樣的情況：請求的接口常常返回很多冗余數據；為了拿到一組數據，不得不發送多個請求；請求到的數據不符合需要的格式，不得不做額外處理；有時某個接口就只少了一個字段……

　　一方面冗余的數據和多次的請求必然會影響產品體驗，另一方面圍繞 Restful API 建立的前後端協作模式會導致大量溝通成本，以致於盡管前後端分離了，很多團隊的開發環節仍然離不開舊時代的“聯調”。

　　解決問題的辦法可以是“深入推進前後端技術融合、全面加強前後端協作溝通、狠抓落實文檔規範……”，這些都是辦法，但對於 facebook 這種體量的產品，靠人力解決上述問題的成本可能是我們無法想象的，而且這也不像是技術人員解決問題的方式，至少 facebook 的工程師不這麽想。他們的解決方案是：前端定義所需數據結構，後端根據數據結構自動查詢數據庫並按指定的數據結構返回數據，用啥取啥，真正實現後端雲服務化。

　　自動化實現，應該永遠是每個程序員解決問題的第一思路。

How？

　　前端向後端發送的 GraphQL 就是一串字符串，它的結構和 json 類似，其中包含增、刪、改、查的指令，括號中定義了一些參數。服務端收到請求就會根據指定的指令、字段和參數返回所需的結構化數據，所見即所得。

具體的教程網上已有不少，在此不做深究。本文目的重在對技術的理解，而非對技術的使用。

Pros？

　　1、網絡層數據無冗余。特別是在移動端，冗余數據可能帶來不小的延遲；

　　2、前後端溝通成本低。根本用不著聯調，後端也用不著寫什麽接口文檔；

　　3、靈活應對各種變化。前端取數據跟吃自助餐似的，私人訂制，予取予求；

Cons？

　　既然這麽牛，怎麽似乎沒啥人用呢？

　　以下參考尤雨溪的回答：https://www.zhihu.com/question/38596306?sort=created

　　1、服務端結構必須符合 GraphQL spec 的規範，這意味著後端需要重寫；

　　2、GraphQL 非常適合特定的前端框架如 React，對於不使用前端框架的公司，就比較尷尬了；

　　3、數據庫查詢這一層的性能優化比較難做，對於 facebook 這不是問題，對於其它公司可能就是個問題；

　　4、GraphQL 需要後端配合，然而由於路徑依賴、風險厭惡等可能的因素，前端要推動 GraphQL 必然會遇到各種阻力。

新技術探究之 GraphQL