What？
GraphQL 是一種類似于 SQL 的結(jié)構(gòu)化查詢語言，由 facebook 于2012年創(chuàng)造，于2015年開源。SQL 在服務(wù)端定義，GraphQL 在客戶端定義，也就是說 GraphQL 將數(shù)據(jù)的操作控制權(quán)從后端轉(zhuǎn)移到了前端。
facebook 創(chuàng)造 GraphQL 的目的是取代以前用的 Restful API，這個方案之漂亮，連 jQuery 之父也忍不住嘖嘖稱嘆：
Why？
傳統(tǒng)的 Restful API 存在的主要問題是無法靈活、精準(zhǔn)的匹配前端的數(shù)據(jù)需求。
首先，產(chǎn)品的需求經(jīng)常變，于是前端需要的接口也經(jīng)常變，比如遇到版本迭代，即便整個數(shù)據(jù)庫結(jié)構(gòu)沒有任何變化，常常也需要重寫或新增很多接口。其次，前端存在不同的平臺，可能對同一類數(shù)據(jù)的請求，web 端和 app 端需要的字段是不一樣的。
后端的接口要做到與前端的需求一一匹配，會極大的增加后端的工作量，于是后端可能會采取這樣的方式：“為多個請求提供一個接口并集，而不是分別為每個請求單獨提供接口”，“有現(xiàn)成可用，就盡量不新增接口”，比如前端需要兩個接口 {1, 2}、{1, 3, 4}，后端只需提供一個接口 {1, 2, 3, 4}。
于是前端對數(shù)據(jù)的需求和后端提供的接口常常無法精準(zhǔn)匹配。前端總會遇到這樣的情況：請求的接口常常返回很多冗余數(shù)據(jù)；為了拿到一組數(shù)據(jù)，不得不發(fā)送多個請求；請求到的數(shù)據(jù)不符合需要的格式，不得不做額外處理；有時某個接口就只少了一個字段……
一方面冗余的數(shù)據(jù)和多次的請求必然會影響產(chǎn)品體驗，另一方面圍繞 Restful API 建立的前后端協(xié)作模式會導(dǎo)致大量溝通成本，需要約定、需要接口文檔、甚至還需要“聯(lián)調(diào)”。
解決問題的辦法可以是“深入推進前后端技術(shù)融合、
