引言
開局兩張圖，內容全靠編～
ok，如圖所示，我在去年曾經寫過一篇文章《閒侃前後端分離的必要性》。嗯，我知道肯定很多人沒看過。所以我做一個總結，其實囉裏八嗦了一篇文章，就是想說一下現在的大型互聯網項目一般是如下兩種架構之一
- 前後端半分離架構
- 前後端分離架構
區別分離和半分離的標誌在於Controller層由不由前端控制，Controller在前端手裏，前端手裏握着組裝數據的邏輯，那就是前後端分離！否則就是半分離！
那麼，半分離和分離的架構是長下面這樣的
ps:中小型公司慎重，不要玩前後端分離架構！前端工作量賊大！
那麼用上了前後端分離架構後，後端的API一般會按照Restful風格來設計！ResultFul推薦每個URL能操作具體的資源,而且能準確描述服務器對資源的處理動作，通常服務器對資源支持get/post/put/delete/等，用來實現資源的增刪改查。前後端分離的架構下，這些api-url是對接的橋樑，採用ResultFul接口地址含義才更清晰、見名知意。
那麼，在實踐RestFul風格的API的有一個致命的缺陷，是神馬類？嗯，帶着你的疑惑開始本文
正文
RestFul的缺陷
假設，此時我們有兩個資源分別是Book和Author，這兩個資源對應的ER圖如下
相應的API有
POST /books
GET /books/{id}
POST /authors
GET /authors/{id}
我們有一個需求，需要查詢id=1的圖書信息！
那我們的請求地址是這樣的
GET /books/1
返回結果是這樣的
[{
"id": 1,
"bookname": Harry Potter,
"price": 56.00,
"author_id": 2
}]這時候前端MM拿到這個結果後，傻了眼！這裏怎麼能直接返回author_id呢，難道直接把author_id顯示在界面上麼？不可能啊，界面上要顯示的是author_name才行！
OK，那麼在這種情況下，有兩種方式可以解決問題！
(1) 跟後端溝通，讓他增加一個接口
嗯，我們複習一下什麼是VO對象。
VO（View Object）：視圖對象，用於展示層，它的作用是把某個指定頁面（或組件）的所有數據封裝起來。
那可以讓後端封裝一個接口，後端幫你把數據拼裝好，提供API如下
GET /bookVOs/1
這樣直接返回的結果就是
[{
"id": 1,
"bookname": Harry Potter,
"price": 56.00,
"author_name": J. K. Rowling
}]當然，因爲你這是臨時讓後端加接口，可能會有如下情形產生
OK，回到正題，這樣做的缺點主要有兩個
- 前後端強耦合在一起，前端界面發生變動，後端VO對象跟着一起變
- 如果BookVO對象在手機端、PC端、APP端的顯示內容都不一樣，你可能在項目中會有BookPcVO類、BookH5VO類、BookAppVO類，VO類大大膨脹！
(2) 自己做適配
這個也很簡單，前端獲得結果後，取出author_id: 2這條記錄，然後再去調用地址
GET /authors/2
得到結果，然後進行組裝顯示！
當然，這個時候會有如下情形產生(這就是我注孤生的原因！)
當然，這種做法的缺點也很明顯
- 返回了一堆前端並不需要的數據
- 徒增前後端的交互次數
ok，通過上面的描述，大家應該能體會到Rest的缺點:REST接口時返回的數據格式、數據類型都是後端預先定義好的，如果返回的數據格式並不是調用者所期望的，調用者在處理上比較麻煩！
那麼，有沒有辦法讓前端自定靈活的使用查詢語句，自己想撈什麼數據就撈什麼數據呢？
有的，那就是Graphql！
Graphql的出現
Graphql其實要這樣理解
Graphql=grap(圖)+query+lanage
是一種基於圖的查詢語言！那麼，這張圖長什麼樣？
OK，首先你要聲明一下，你的圖結構，嗯，用的就是Graphql的語法啦，像下面這樣
type Book {
id: Int
bookname: String
authors: [Author]
}
type Author {
id: Int
name: String
age: String
}
type Query {
getBook(id: Int): Book
}
schema {
query: Query
}對上面的語句進行一下解釋。這裏一共聲明瞭三個類Book、Author、Query！其實，Book和Author大家都可以猜都出來是指啥，需要注意的一點是authors: [Author]這個地方，用了一個[]的語法，這代表Author是一個數組！
唯一需要說明的是，Query是什麼鬼？
Query在這兒表明了該類型是這張圖的入口，也就是根節點！我們的查詢必須從根節點裏的屬性開始！這裏我爲了便於說明，只列了一個屬性，也就是getBook，該屬性是入口，必須從入口開始查！
那麼，生成的圖是長下面這樣的
這裏還有一個Resolver的概念，就是說，GragphQL解析到getBook方法的時候，方法體內容是啥？是在Resovler中定義的，我這裏就不貼配置了，感興趣的可以自己去官網閱讀！
OK,接下來就是第二個問題，怎麼查？
根據上面我說的，只能從根開始，根是getBook，那語句怎麼寫呢？如下所示
那你想加個字段，顯示作者名字呢？直接像下面這麼寫
採用這種語法結構，後端的數據模型就變成了一張圖，前端可以定製化自己的輸出結構，同時可以減少前後端的溝通成本，提高靈活性！
一些疑問
(1)java語言中，對Graphql的支持如何？
在java中，有個jar包爲graphql-java-tools提供了對Java的支持。
另外，考慮到現在大多是springboot項目，有大神封裝好了starter包，供你們的springboot項目使用！
只需在項目中引入
<!-- graphql -->
<dependency>
<groupId>com.graphql-java</groupId>
<artifactId>graphql-spring-boot-starter</artifactId>
<version>4.0.0</version>
</dependency>
<dependency>
<groupId>com.graphql-java</groupId>
<artifactId>graphql-java-tools</artifactId>
<version>4.3.0</version>
</dependency>即可讓你的springboot項目擁有graphql的功能，非常方便！
(2)這樣做不會加重前後端工作量麼？
說句實在話，摸着良心說，前期確實加重了前後端的工作量！
對前端而言：需要去了解Graphql的語法！
對後端而言：不僅需要了解Graphql的語法，還需要去編寫Schema和Resovler！
所以短期內，確實增加了工作量！但是從長遠來看，同時降低了前後端的工作量！第一，前端不用瞭解後端的數據結構，GraphQL自己生成可交互式的接口文檔，前端可以自己測試調用
第二，後端不用在編寫什麼接口文檔，GrapQL自動幫你生成，用起來非常舒心！
總結
本文介紹了Rest的缺點，以及Graphql的基本知識，希望大家有所收穫！