GraphQL初探
1.什么是 GraphQL 缩举？
A query language for your API
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.
GraphQL 是 Facebook 在2012年創(chuàng)建沮榜、2015年形成規(guī)范的一種應(yīng)用層查詢語言
很多優(yōu)點：
- 客戶端可以自定義查詢語句妇智，通過自定義不僅提高了靈活性皆刺，而且服務(wù)端只返回客戶端所需要的數(shù)據(jù)译隘，減少網(wǎng)絡(luò)的開銷好啰，提高了性能
- 服務(wù)端收到客戶端的請求，首先做類型檢查片酝，及時反饋，而且更加安全焚廊；這個對于node.js 就效果很明顯了捉捅。
- 自動生成文檔撤防，降低維護成本；
- 服務(wù)端可以通過新增字段锯梁，棄用字段即碗，避免版本的繁雜和紊亂
上面所述也都是Rest API弊端，GraphQL卻能很好的解決他們陌凳。
[圖片上傳失敗...(image-e3e659-1529652402420)]
大家都應(yīng)該知道REST API需要為每個請求匹配相應(yīng)的數(shù)據(jù)需求剥懒。而GraphQL的優(yōu)點在與客戶端數(shù)據(jù)要求發(fā)生變化時, 不需要修改后端. 因此, 你不必因為客戶端數(shù)據(jù)需求的變更而改變你的后端。這解決了管理REST API中的最大的問題合敦。
GraphQL的特征：
- 可描述性的：使用GraphQL初橘，你獲取的都是你想要的數(shù)據(jù)，不多也不會少充岛；
- 分級性的：GraphQL天然遵循對象間的關(guān)系保檐，通過一個簡單的請求，我們可以獲取到一個對象及其相關(guān)的對象崔梗，比如說夜只，通過一個簡單的請求，我們可以獲取一個作者和他創(chuàng)建的所有文章蒜魄，然后可以獲取文章的所有評論扔亥；
- 強類型的：使用GraphQL的類型系統(tǒng)场躯，我們可以描述能夠被服務(wù)器查詢的可能的數(shù)據(jù)，然后確保從服務(wù)器獲取到的數(shù)據(jù)和我們查詢的一致旅挤；
- 不做語言限制：并不綁定于某一特定的語言踢关，實際上現(xiàn)在已經(jīng)有一些不同的語言有了實踐；
- 兼容于任何后臺：GraphQL不限于某一特定數(shù)據(jù)庫粘茄，可以使用已經(jīng)存在的數(shù)據(jù)签舞，代碼，甚至可以連接第三方的APIs.
- 好反省的：GraphQL服務(wù)器能夠查詢架構(gòu)的細節(jié)柒瓣。
總結(jié)：
它的官方宣傳語是“為你的 API 量身定制的查詢語言”儒搭，用傳統(tǒng)的方式來解釋就是：
相當于將你所有后端 API 組成的集合看成一個數(shù)據(jù)庫，用戶終端發(fā)送一個查詢語句嘹朗，你的 GraphQL 服務(wù)解析這條語句并通過一系列規(guī)則從你的“ API 數(shù)據(jù)庫”里面將查詢的數(shù)據(jù)結(jié)果返回給終端师妙，而 GraphQL 就相當于這個系統(tǒng)的一個查詢語言，像 SQL 之于 MySQL 一樣屹培。
來看看 GraphQL 查詢demo
Graph的查詢語句非常類似JSON默穴，如客戶端的查詢語句
{
user{
name
sex
}
}
查詢用戶信息的name和sex字段數(shù)據(jù)，服務(wù)端返回結(jié)果如
{
"data": {
"user": {
"name": "zhaiqianfeng",
"sex": "男"
}
}
}
使用如下查詢語句時
{
user{
name
intro
}
}
{
"data": {
"user": {
"name": "zhaiqianfeng",
"intro": "博主褪秀，專注于Linux,Java,nodeJs,Web前端:Html5,JavaScript,CSS3"
}
}
}
2. GraphQL 組成
GraphQL的核心包括Query,Mutation,Schemas等等蓄诽，每個概念下又有一些子概念,下面分別做簡單的介紹：
Query
Queries用做讀操作，也就是從服務(wù)器獲取數(shù)據(jù)媒吗。
Queries定義了我們對模式執(zhí)行的行為仑氛。下面是一個簡單的查詢及相應(yīng)的結(jié)果：
客服端：
// Basic GraphQL Query
{
author {
name
posts {
title
}
}
}
服務(wù)端返回：
// Basic GraphQL Query Response
{
"data": {
"author": {
"name": "Chimezie Enyinnaya",
"posts": [
{
"title": "How to build a collaborative note app using Laravel"
},
{
"title": "Event-Driven Laravel Applications"
}
]
}
}
}
===============================================================================================》》》
Mutation
傳統(tǒng)的API使用場景中，我們會有需要修改服務(wù)器上數(shù)據(jù)的場景闸英，mutations就是應(yīng)這種場景而生锯岖。mutations被用以執(zhí)行寫操作，通過mutations我們會給服務(wù)器發(fā)送請求來修改和更新數(shù)據(jù)甫何，并且會接收到包含更新數(shù)據(jù)的反饋出吹。mutations和queries具有類似的語法，僅有些許的差別辙喂。
mutation UpdateAuthorDetails($authorID: Int!, $twitterHandle: String!) {
updateAuthor(id: $authorID, twitterHandle: $twitterHandle) {
twitterHandle
}
}
在mutation中以數(shù)據(jù)為載物發(fā)送捶牢，比如上面的例子中，我們發(fā)送了下面的數(shù)據(jù)：
# Update data
{
"authorID": 5,
"twitterHandle": "ammezie"
}
更新完成后巍耗，我們將從服務(wù)器獲取以下內(nèi)容作為反饋秋麸。反饋數(shù)據(jù)中包含我們更新的數(shù)據(jù)
# Response after update
{
"data": {
"id": 5,
"twitterHandle": "ammezie"
}
}
和queries類似，mutations也能夠接受炬太，多重fields,不過queries和mutations的一個重大不同之處在于灸蟆，為了保證數(shù)據(jù)的完整性mutations是串形執(zhí)行，而queries可以并行執(zhí)行亲族。
===============================================================================================》》》
Schema
GraphQL中非常重要的一個概念是Schema, Schema由服務(wù)端來定義次乓，用于定義API接口吓歇，并依靠Schema來生成文檔以及對客戶端請求進行校驗。Schema只是一個概念票腰，它是由各種數(shù)據(jù)類型及其字段組成，而每個類型的每個字段都有相應(yīng)的函數(shù)來返回數(shù)據(jù)女气，這是其靈活的關(guān)鍵所在杏慰，如Schema
Schemas 描述了 數(shù)據(jù)的組織形態(tài) 以及服務(wù)器上的那些數(shù)據(jù)能夠被查詢，Schemas提供了你數(shù)據(jù)中可用的數(shù)據(jù)的對象類型炼鞠，GraphQL中的對象是強類型的缘滥，因此schema中定義的所有的對象必須具備類型。類型允許GraphQL服務(wù)器確定查詢是否有效或者是否在運行時谒主。Schemas可用是兩種類型Query和Mutation朝扼。
示例一：
type User{
name: String
sex: String
intro: String
}
type Query {
user:User
}
上面定義了兩個類型，User和Query：User有三個字段分別是name霎肯、sex和intro擎颖；Query是個特殊的類型，用于查詢數(shù)據(jù)观游，內(nèi)含user字段搂捧；
如果客戶端輸入的如下查詢語句：
{
user{
name
sex
}
}
示例二：
又或者是下面是一個示例：
type Author {
name: String! // 必填字段 用！表示
posts: [Post] // 可選字段 [] 表示數(shù)組字段
}
schemas定義了一個Author對象懂缕，它包含兩個fields(name和posts),這意味著當我們操作（讀仍逝堋）Author時，我們只能使用name和fields,每個field都可以是必須的或者可選的,比如上面的namefield是必須的搪柑，因為其后有符號!,而posts是可選的聋丝。
?
3. GraphQL vs. REST
GraphQL目前被認為是革命性的API工具，因為它可以讓客戶端在請求中指定希望得到的數(shù)據(jù)工碾，而不像傳統(tǒng)的REST那樣只能呆板地在服務(wù)端進行預(yù)定義弱睦。這樣它就讓前、后端團隊的協(xié)作變得比以往更加的通暢倚喂，從而能夠讓組織更好地運作每篷。而實際上，GraphQL與REST都是基于HTTP進行數(shù)據(jù)的請求與接收端圈，而且GraphQL也內(nèi)置了很多REST模型的元素在里面焦读。
從API的各個組件分別來討論GraphQL和REST都分別是如何處理的。
資源（Resources）
REST的核心思想就是資源舱权，每個資源都能用一個URL來表示矗晃，你能通過一個GET請求訪問該URL從而獲取該資源。根據(jù)當今大多數(shù)API的定義宴倍，你很有可能會得到一份JSON格式的數(shù)據(jù)響應(yīng)张症，整個過程大概是這樣：
GET /books/1
{
"name": "Black Hole Blues",
"author": {
"firstName": "zhang",
"lastName": "liang"
}
// ... more fields here
}
以上形式它的路徑與所請求到的數(shù)據(jù)是高度耦合的仓技，基本無法變動。
在這一點上GraphQL就大為不同俗他，因為在GraphQL里這兩個概念是完全分離的脖捻。比如說在你的schema定義中，你可能會有Book和Author兩個類型（type）：
type Book {
id: ID
title: String
published: Date
price: String
author: Author
}
type Author {
id: ID
firstName: String
lastName: String
books: [Book]
}
注意這里我們雖然定義了數(shù)據(jù)類型兆衅，但卻不知道該如何獲取這些數(shù)據(jù)地沮。這是REST與GraphQL的一個核心差異：資源的描述信息與其獲取方式相分離。
如果要去訪問某個特定的book或者author資源羡亩，我們需要在schema中創(chuàng)建一個Query類型：
type Query {
book(id: ID!): Book
author(id: ID!): Author
}
前端可以這樣請求我們的數(shù)據(jù)
GET /graphql?query={ book(id: "1") { title, author { firstName } } }
{
"title": "Black Hole Blues",
"author": {
"firstName": "Janna",
}
}
小結(jié)：
異同點有：
相同：
- 都有資源這個概念摩疑，而且都能通過ID去獲取資源。
- 都可以通過HTTP GET方式來獲取資源
- 都可以使用JSON作為響應(yīng)格式
不同：
- 在REST中畏铆，你所訪問的路徑就是該資源的唯一標識（ID）雷袋；在GraphQL中，該標識與訪問方式并不相關(guān)
- 在REST中辞居，資源的返回結(jié)構(gòu)與返回數(shù)量是由服務(wù)端決定楷怒；在GraphQL，服務(wù)端只負責定義哪些資源是可用的速侈，由客戶端自己決定需要得到什么資源率寡。簡單來說就是前者中 是后端強行給你一些數(shù)據(jù)要通過HTTP，而后者是將一些數(shù)據(jù)定義在了服務(wù)端倚搬，讓前端自助從這些數(shù)據(jù)中來選擇性的通過HTTP到前端冶共。
===============================================================================================》》》
路由（URL Route） vs. GraphQL Schema
如今的REST API通常會由一系列的URL端點組成：
GET /books/:id
GET /authors/:id
GET /books/:id/comments
POST /books/:id/comments
你可以把這種API的形態(tài)稱之為線性結(jié)構(gòu)——因為這就是一個列表嘛。當你要獲取數(shù)據(jù)時每界，第一個事情就是搞清楚你要訪問的是哪個端點捅僵。
在GraphQL中——可以通過查看GraphQL schema獲得相關(guān)信息：
type Query {
book(id: ID!): Book
author(id: ID!): Author
}
type Mutation {
addComment(input: AddCommentInput): Comment
}
type Book { ... }
type Author { ... }
type Comment { ... }
input AddCommentInput { ... }
REST會使用類似GET、POST這樣的動詞去請求相同的URL來表示這到底是一個讀操作還是寫操作眨层，而GraphQL會使用不同的預(yù)定義類型：Mutation和Query庙楚。在GraphQL請求中，你可以通過不同的關(guān)鍵字進行不同的操作：
query { ... }
mutation { ... }
這里的Query類型定義與上面的REST路由是完全契合的趴樱，同樣表示了數(shù)據(jù)的訪問入口馒闷，因此這是GraphQL中最能與REST的URL端點所對應(yīng)的概念。
如果是對資源的簡單查詢叁征，GraphQL與REST是類似的纳账，都是通過指定資源的名稱以及相關(guān)參數(shù)來取得，但不同的是捺疼，在GraphQL中疏虫，你可以根據(jù)資源之間的關(guān)聯(lián)關(guān)系來發(fā)起一個復(fù)雜請求，而在REST中你只能定義一些特殊的URL參數(shù)來獲取到特殊的響應(yīng)，或者是通過發(fā)起多個請求卧秘、再自行把響應(yīng)得到的數(shù)據(jù)進行組裝才行呢袱。
===============================================================================================》》》
路由處理器（Route Handlers）vs. 解析器（Resolvers）
首先使用Express實現(xiàn)一個hello world：
app.get('/hello', function (req, res) {
res.send('Hello World!')
})
golang gin :
router := gin.Default()
router.GET("/hello", func(c *gin.Context) {
c.String(http.StatusOK, "Hello World")
})
從上面例子我們可以看到一個REST API請求的的生命周期：
- 服務(wù)器收到請求并提取出HTTP方法名（比如這里就是GET方法）與URL路徑
- API框架找到提前注冊好的、請求路徑與請求方法都匹配的代碼
- 該段代碼被執(zhí)行翅敌，并得到相應(yīng)結(jié)果
- API框架對結(jié)果進行序列化羞福，添加上適當?shù)臓顟B(tài)碼與響應(yīng)頭后，返回給客戶端
GraphQL差不多也是這樣工作的哼御，我們來看下這個對應(yīng)的
const resolvers = {
Query: {
hello: () => {
return 'Hello world!';
},
},
};
發(fā)起一個查詢：
query {
hello
}
返回如下：
{ "hello": "Hello, world!" }
服務(wù)器對一個GraphQL請求的執(zhí)行過程：
- 服務(wù)器收到HTTP請求坯临，取出其中的GraphQL查詢
- 遍歷查詢語句，調(diào)用里面每個字段所對應(yīng)的Resolver恋昼。在這個例子里，只有Query這個類型中的一個字段hello
- Resolver函數(shù)被執(zhí)行并返回相應(yīng)結(jié)果
- GraphQL框架把結(jié)果根據(jù)查詢語句的要求進行組裝
上圖形象地說明了使用REST和GraphQL進行多種資源獲取的方式的差異
這里放上一個現(xiàn)在體驗 在線體驗GraphQL
首先說一下單一的入口這一點赶促。傳統(tǒng)的 RESTful API 里液肌，不管前端還是后端都要對 API 做管理，一是版本管理鸥滨，二是路徑管理嗦哆，非常麻煩，增加了工程管理的復(fù)雜度婿滓。但是如果使用 GraphQL老速，只需要一個入口就可以了。剛剛也說到 GraphQL 相當于一個數(shù)據(jù)庫凸主，它的入口只有一個橘券，我們只需要訪問這個入口，將我們要查詢的語句發(fā)送給這個入口卿吐，就可以拿到相應(yīng)的數(shù)據(jù)旁舰，所以說它是一個單端點+多樣化查詢方式的這么一個結(jié)構(gòu)。
第二點是文檔嗡官，這里文檔雖然不能完全替代傳統(tǒng)的文檔箭窜，但是它能在一定程度上方便我們。傳統(tǒng)的 RESTful API 文檔管理衍腥，市面上有很多工具磺樱，像 Swagger、阿里開源的 RAP 以及 showdoc 等婆咸。但使用這些 API 文檔管理工具的時候其實是有一定的學(xué)習(xí)成本的竹捉。像 Swagger， 可能對于老手來說使用起來不是很復(fù)雜擅耽，但是對于剛上手的開發(fā)者來說上手還是需要一點時間的活孩。然后還有在使用這些平臺的時候都會遇到讓人頭痛的“ API 和文檔同步”的問題，很多時候需要自己去做 API 和文檔同步的插件來解決。
如果使用 GraphQL 就可以在一定程度上解決 API 文檔的一些問題：在做 GraphQL 類型定義的時候我們可以對類型以及類型的屬性增加描述 (description) , 這相當于是對類型做注釋憾儒，當類型被編譯以后就可以在相應(yīng)的工具上面看到我們編輯的類型詳情了
除了GraphiQl 一款瀏覽器在線調(diào)試和文檔查看工具外（代碼中給予演示Ｑ恕）
GraphQL 還有一個比較棒的功能，就是每一個 GraphQL 類型 其實相當于 mongo 里面的一個 collection起趾，或者 mongoose 里面的 Model, 而每一個類型之間關(guān)系也可以用工具很形象的表現(xiàn)出來诗舰。像系統(tǒng)上用到這么一個模型，它對應(yīng)到哪些和它有關(guān)系的模型都高亮出來了训裆。
使用 GraphQL 的第三點好處就是可以避免數(shù)據(jù)冗余眶根。我們在傳統(tǒng)的 RESTful 處理冗余的數(shù)據(jù)字段大約有這么三種處理方式：
- 一是前端選擇要不要展示這些字段；
- 二是要么做一個中間層（BFF）去篩選這些字段边琉，然后再返回終端來展示出來属百；
- 三則比較傳統(tǒng)也比較麻煩，還不一定能生效变姨，就是前端和后端去做約定族扰，如果說這一個接口這一個字段已經(jīng)不要，可以和后端商量一下把這個刪掉定欧，但是有一種情況可能造成冗余字段刪不掉的渔呵，那就是后端的同學(xué)做這個接口可能是“萬能接口”，也就是說這個接口在這個頁面會用砍鸠，在另外一個頁面也能用扩氢，在這個應(yīng)用會用，在另外一個應(yīng)用也可能會用爷辱，多端之間存在部分數(shù)據(jù)共享录豺，后端同學(xué)為了方便可能會寫這么一個“萬能”的接口來應(yīng)付這種情況，久而久之托嚣，發(fā)現(xiàn)字段冗余到很多了巩检，但是隨便刪除又可能會影響到很多地方，導(dǎo)致這個接口大而不能動示启，所以前后端都不得不忍受它兢哭。
但如果使用 GraphQL，就可以避免接口字段冗余這個問題夫嗓，使用 GraphQL 的話迟螺，前端可以自己決定自己想要的返回的數(shù)據(jù)結(jié)構(gòu)。
GraphQL 實際上是一種查詢語言舍咖，我們在使用時就像是在數(shù)據(jù)庫里面查詢數(shù)據(jù)一樣矩父，查詢的某一個數(shù)據(jù)要哪些字段可以在查詢語句里寫好，要哪些字段就返回給我們哪些字段排霉。
最重要一點當然是數(shù)據(jù)聚合窍株，數(shù)據(jù)聚合在使用傳統(tǒng)的 RESTful 的方式時有多種解決方案：
一種前端發(fā)針對這個頁面上的多數(shù)據(jù)源單獨發(fā)起數(shù)據(jù)請求，然后一一展示出來，這樣可能會出現(xiàn)頁面數(shù)據(jù)加載不同步的情況球订。
第二種就是開發(fā)做數(shù)據(jù)拼裝的中間層（BFF）后裸，用于拼裝后端提供的數(shù)據(jù)，然后返回給前端冒滩。
還有一種 那就是后端同學(xué)編寫針對頁面的 API微驶，即所謂膠水代碼，來拼接各個服務(wù)的數(shù)據(jù)开睡，返回給前端因苹。
