GraphQL分享理論篇

前陣子在公司內部分享了GraphQL，今天抽空總結並補充一下：

目前專案開發比較流行的是前臺後分離模式，後臺提供介面，前臺呼叫介面，介面書寫遵循流行的RESTful API規範

• REST 由 Roy Thomas Fielding 在他2000年的博士論文中提出的。
• REST，即 Representational State Transfer(表述性狀態傳遞) 的縮寫。
• 如果一個架構符合 REST 原則, 就稱它為 RESTful 架構

RESTful API 特點

• 每一個 URI 代表一種資源；
• 充分利用 HTTP 協議本身語義；
• 客戶端和伺服器器之間，傳遞這種資源的某種表現層；
• 客戶端通過四個 HTTP 動詞，對伺服器器端資源進行操作，實現 ” 表現層狀態轉化 ” 。

RESTful API 缺陷

• 一個介面僅操作單一資源
• 各個資源是獨立的，完成一個頁面需要呼叫多個介面
• 資料冗餘，靈活性差
• 需專門維護文件 (v1, v2)

有時候開啟某個頁面，我們需要呼叫多個介面。
有時候我們不需要的欄位後臺也給我們返回了，這是由後臺控制的。

而GraphQL可以完美的解決上面的問題

GraphQL是….

• Facebook 2012年開發，2015年開源
• 應用層的API查詢語言
• 在服務端的執行資料查詢語言的規範 (我建議你先抽半個小時瀏覽下心裡有個大概)

GraphQL的特點

• 強型別
• 單一入口
• 一個請求獲取所有所需資源
• 內省系統

為什麼叫GraphQL

圖（Graph）是一種複雜的非線性結構，在圖結構中，每個元素都可以有零個或多個前驅，也可以有零個或多個後繼，也就是說，元素之間的關係是任意的。

使用GraphQL 注意的問題

• 效能問題 (請求少了，但查詢多了)
• GraphQL 在前端如何與檢視層、狀態管理方案結合
• 安全, Limit, timeout N+1 查詢

關於從規範裡提煉的

• GraphQL是一種資料描述語言，而非程式語言，因此GraphQL缺乏用於描述數學表示式的標點符號。
• 註釋只能用 # ，可以使用末尾的逗號提高可讀性。
• GraphQL的命名是大小寫敏感的，也就是說name，Name，和NAME是不同的名字。
• 一個文件可以包含多個操作和片段的定義。一個查詢文件只有包含操作時，伺服器才能執行。
• 如果一個文件只有一個操作，那這個操作可以不帶命名或者簡寫，省略掉query關鍵字和操作名。

下一篇 實戰

參考：
http://graphql.org/graphql-js/