GraphQL 簡介

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 的工程師不這麼想。

　　近年來 web 開發的基本趨勢是從後向前移，愈來愈多的邏輯在前端處理，可是接口仍然須要後端提供，前端老是要等後端喂接口，後端寫的接口老是要等前端來驗證，那麼爲何 SQL 不能讓前端來寫呢？這就是 GraphQL 提出的解決方案：由前端來定義所需數據、發送查詢命令，服務器根據請求自動查詢數據庫並按指定的數據結構返回數據，用啥取啥，後端只提供服務，而再也不關心具體的業務。

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

 

How？

      

　　前端向服務端發送的 GraphQL 就是一串字符串，它的結構和 json 相似，其中包含增、刪、改、查的指令，括號中定義了一些參數。服務端收到請求就會根據指定的指令、字段和參數返回所需的結構化數據。簡單的說，就是前端發送只有屬性名，而沒有值的 json，服務端返回填充了值的 json。

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

 

Pros？

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

　　二、先後端溝通成本低。根本用不着聯調，後端也用不着寫什麼接口文檔；

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

 

Cons？

　　既然這麼牛，怎麼彷佛沒啥人用呢？

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

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

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

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

　　四、GraphQL 須要後端配合，然而因爲路徑依賴、風險厭惡等可能的因素，前端要推進 GraphQL 必然會遇到各類阻力。