引言
開局兩張圖,內容全靠編~
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的基本知識,希望大家有所收穫!