這裡記錄着小洋童鞋在前端道路上的所思所想所感。
生命在于折騰，不在折騰中崩潰，就在折騰中涅槃。
首先給大家簡單的介紹一下 graphql 特性，graphql 其實是一種和後端交換資料的協定，像通過 sql 語言可以操作資料庫一樣，graphql 通過 schema 的方式來控制資料，并約定提供以下能力：
可以說很多資料交換的情景都可以使用 graphql 的概念，我們就先基于 express 來快速打造一個 http 伺服器 ( graphql 官方并沒有說隻限于 http) 用最簡單的方式體驗一下 graphql，我們的項目起始于 package.json：
$npm install 以後我們就可以愉快的玩耍了，首先搭好程式入口，本地服務以及處理 graphql 請求的 handler：
上述代碼建立了入口 index.js 、本地服務 server.js 以及 schema 執行個體 schema.js ，至此我們的 graphql 服務的骨架就出來了，下面我們隻要來把 schema.js 填充完整就可以體驗 graphql 啦~
我們可以按照上述<code>描述資料</code>，<code>篩選資料</code>然後<code>擷取資料</code>的順序生成測試代碼感受一下 graphql 的魅力吧~
首先我們先建立一個模拟資料源 todo list:
todo list 是一個元素為 todo object 的數組，由于我們要給用戶端提供篩選及自省的能力，是以我們要通過 graphql 的 type 來描述所有組織結構，首先我們來描述元素 todo object
那麼 todo list 顯而易見就是 <code>new graphqllist(todotype)</code> 啦，即元素為 todotype 的數組。
有了資料源我們就可以愉快的通過 graphql schema 來取資料啦，我們的第一個 schema 就先為擷取整個 todo list 吧，先在伺服器上注冊一個處理 graphql 請求的方法：
之前已經建立了一個端口為3000，路由為 /graphql 的 graphql api，至此終于可以 $node index.js 開始我們的 graphql 之旅啦~
比如我們可以通過下面的 query 來擷取 todos 下的 title ，由于 todos 是數組是以結果對應也是數組：
注：通過控制台，postman等均可構造 post 請求驗證結果，本文所有請求都通過 curl 來構造（包括添加 contenttype 請求頭及 data）。
在介紹自省之前，我們可以先了解一下域，每個 graphql 根域都有 __schema 域，這個域有一個子域叫 querytype。我們可以通過查詢這些域來了解 graphql 伺服器支援那些查詢，按照 object 的方式了解其實就是通過對象的屬性可以了解其結構及内容
看到上面的結果大家應該都有感覺了，其實 graphql 請求的成功與否與接口的 schema 設計結構息息相關，所有的資料結構查詢都是按協商好的規則進行的，還記得我們聲明的 graphqlschema 是怎麼寫的嗎？
發現結果是一一對應的了吧，哈哈~ 可以記住這個“萬能查詢”，同時 graphql 也提供了__type, __typekind, __field, __inputvalue等等的關鍵字來檢測接口所支援查詢的屬性，比如我們現在已經知道了“/garphql”這個 api 會傳回一個對象數組，那我想知道他包含的對象是什麼結構咋變咧？
沒錯我們可以通過限定 __type 去查已經注冊的 "todo" 對象來自省接口，還有很多關鍵字方法都可以達到上述的效果本文就不一一列舉了。細心的同學發現上面 __type(name: todo) 的用法了吧，同樣也可以用到我們的代碼中來查詢具體某一條的 todo 對象:
有查詢資料當然也有修改資料，mutation 查詢和普通查詢請求（query）的重要差別在于 mutation 操作是按照順序執行的，即多次修改資料後再查詢，其傳回一定是最後一次修改後的結果：
正如官方所說 graphql 是一個查詢語言，而且目前還未完成，未來也可能會有更多更大的變動，但已經拓寬了我們的思路，讓我們看到了更多的可能性。目前 graphql 利好主要是在于前端的開發效率，落地時需要服務端的全力配合，也存在着一定的安全風險（暴力破解接口能力等），最大的性能瓶頸可能來自于資料庫查詢，但究竟好不好用，關鍵是看你怎麼用了，對吧？ 我們仍在前行，陽光總在風雨後。