掃二維碼與項(xiàng)目經(jīng)理溝通
我們?cè)谖⑿派?4小時(shí)期待你的聲音
解答本文疑問/技術(shù)咨詢/運(yùn)營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
2015年， Facebook開源GraphQL 。 此后，它在前端Web中大受歡迎。 傳統(tǒng)的REST API有何不足？GraphQL優(yōu)勢(shì)何在？在本文中， 我們將深入探討GraphQL的設(shè)計(jì)原則，比較 GraphQL 與 REST 的異同，并討論GraphQL 相對(duì)其他架構(gòu)的優(yōu)點(diǎn)。
1 你的 API 應(yīng)該用哪項(xiàng)技術(shù)？
自從 2015 年 Facebook 開源 GraphQL 規(guī)范以來，它就在前端 Web 開發(fā)中迅速流行起來。
為什么這種新技術(shù)會(huì)突然流行起來？
與傳統(tǒng) REST API 相比，GraphQL 提供了哪些優(yōu)勢(shì)？
我們將討論 GraphQL 的設(shè)計(jì)原則，比較 GraphQL 與 REST 中的相同請(qǐng)求，并 深入探討 GraphQL 相對(duì)其他架構(gòu)的優(yōu)點(diǎn) 。
為理解 GraphQL 作為 API 架構(gòu)的好處，我們要討論 API 在客戶端 - 服務(wù)器結(jié)構(gòu)中的作用。API（應(yīng)用程序編程接口）是一個(gè)中間層，它允許服務(wù)器從客戶端接收結(jié)構(gòu)化數(shù)據(jù)請(qǐng)求，并針對(duì)請(qǐng)求的數(shù)據(jù)發(fā)送結(jié)構(gòu)化的響應(yīng)。設(shè)計(jì) API 架構(gòu)的方法有很多種。
讓我們來研究一下促使 GraphQL 適合現(xiàn)代化 Web 應(yīng)用程序的重要基本設(shè)計(jì)原則。
2 GraphQL 服務(wù)器的設(shè)計(jì)原則
GraphQL 規(guī)范概括了 5 個(gè)設(shè)計(jì)原則，這使其成為現(xiàn)代前端開發(fā)的良好解決方案。 我們看一下 GraphQL 的設(shè)計(jì)原則，并以 Facebook 新聞推送作為我們的用例。
查詢?yōu)榉謱咏Y(jié)構(gòu)，使用將查詢與響應(yīng)數(shù)據(jù)1對(duì)1匹配的分層和嵌套字段格式。查詢和響應(yīng)的形狀類似于樹，可查詢每個(gè)項(xiàng)的其他嵌套字段。在 Facebook 的新聞推送中，這種結(jié)構(gòu)允許一個(gè)查詢返回一個(gè)帖子列表、每個(gè)特定帖子的評(píng)論，以及每個(gè)評(píng)論的點(diǎn)贊。
該結(jié)構(gòu)以產(chǎn)品為中心，關(guān)注前端希望如何接收數(shù)據(jù)，并構(gòu)建交付所需的運(yùn)行時(shí)。這使得 Facebook 的新聞推送可通過一次請(qǐng)求從后端獲取需要的所有數(shù)據(jù)，使服務(wù)器按照 GraphQL 的規(guī)范從不同的端點(diǎn)獲取數(shù)據(jù)。
它使用特定于應(yīng)用程序的類型系統(tǒng)，該系統(tǒng)使開發(fā)人員能在執(zhí)行前確保查詢使用了有效類型，并且語法正確。例如，新聞推送的 GraphQL 模式要求字段“user”必須包含一個(gè)字符串，而“l(fā)ikes”必須包含一個(gè)數(shù)字。如果查詢?cè)噲D添加不同類型的輸入，GraphQL 將在執(zhí)行查詢前拋出一個(gè)錯(cuò)誤。
GraphQL 查詢是在客戶端指定的，因此，客戶端確切知道它將以何種格式接收數(shù)據(jù)。這意味著，如果前端請(qǐng)求的格式是包含用戶名、評(píng)論和點(diǎn)贊的 post 數(shù)據(jù)，那么來自 Facebook 新聞推送的請(qǐng)求會(huì)構(gòu)建在一個(gè)對(duì)象中，而不是像其他架構(gòu)那樣構(gòu)建多個(gè)單獨(dú)的數(shù)據(jù)塊。
使用 GraphQL 的服務(wù)器結(jié)構(gòu)必須是內(nèi)省的，或者可由 GraphQL 自己查詢。于是才有了像 GraphiQL 或 GraphQL playground 這樣的強(qiáng)大工具。這兩種工具都可以讓 Facebook 開發(fā)人員準(zhǔn)確地看到在他們的服務(wù)器上使用了哪些查詢和字段。
為討論向 GraphQL 的轉(zhuǎn)變，以及這些設(shè)計(jì)原則如何給開發(fā)帶來好處。
我們首先深入了解傳統(tǒng)的 REST API 架構(gòu)和它的不足之處。
3 傳統(tǒng)的 RESTful 架構(gòu)
REST 架構(gòu)的設(shè)計(jì)范式側(cè)重于分配 HTTP 請(qǐng)求方法（GET、POST、PUT、PATCH、DELETE）和 URL 端點(diǎn)之間的關(guān)系。
在 REST 架構(gòu)中，方法和端點(diǎn)的每個(gè)組合得到不同的封裝功能。如果客戶端需要的數(shù)據(jù)特定端點(diǎn) / 方法不提供，則可能需要額外請(qǐng)求。從 REST 請(qǐng)求返回的數(shù)據(jù)格式依賴于端點(diǎn)—不能保證這些數(shù)據(jù)會(huì)按照前端需要的方式進(jìn)行格式化。為使用來自響應(yīng)的數(shù)據(jù)（格式與缺省情況下從端點(diǎn)返回的格式不同），必須在客戶端編寫數(shù)據(jù)解析和數(shù)據(jù)操作。
接下來，讓我們看看 GraphQL 規(guī)范與 REST 的不同之處，以及它的優(yōu)點(diǎn)。這些優(yōu)點(diǎn)使這個(gè)新架構(gòu)成為特別適合解決客戶端和服務(wù)器之間數(shù)據(jù)交付問題的解決方案。
4 GraphQL 架構(gòu)
與 RESTful API 一樣，GraphQL API 設(shè)計(jì)用于處理 HTTP 請(qǐng)求并對(duì)這些請(qǐng)求提供響應(yīng)。無論如何，這就是相似之處。REST API 構(gòu)建在請(qǐng)求方法和端點(diǎn)之間的連接上，而 GraphQL API 被設(shè)計(jì)為只通過一個(gè)端點(diǎn)，始終使用 POST 請(qǐng)求進(jìn)行查詢，其 URL 通常是 yourdomain.com/graphql。
請(qǐng)求到達(dá) GraphQL 端點(diǎn)后，客戶端請(qǐng)求的載荷完全在請(qǐng)求體中處理。這個(gè)請(qǐng)求體必須遵循 GraphQL 規(guī)范，API 必須有適當(dāng)?shù)姆?wù)器端邏輯來處理這些請(qǐng)求并提供適當(dāng)?shù)捻憫?yīng)。
這提供了比 RESTful API 更流暢的客戶端體驗(yàn)，后者可能要求客戶端針對(duì)多個(gè)數(shù)據(jù)塊發(fā)出多個(gè)請(qǐng)求，并在數(shù)據(jù)返回后進(jìn)行操作。
為了闡明 GraphQL 是如何實(shí)現(xiàn)這一點(diǎn)的，讓我們分解一下 GraphQL 服務(wù)器的結(jié)構(gòu)。
5 GraphQL 服務(wù)器
啟用 GraphQL 邏輯的服務(wù)器端邏輯由定義了服務(wù)器功能的 Documents 組成。這些 Documents 包含可執(zhí)行文件和類型系統(tǒng)定義。顧名思義，類型系統(tǒng)定義為每個(gè)數(shù)據(jù)字段定義可接受的類型和格式輸入及結(jié)果。
可執(zhí)行文件包含要處理的可能的操作列表，其中包括操作類型（查詢、修改或訂閱）、操作名稱、要查詢或?qū)懭氲淖侄魏鸵粋€(gè)選擇集，該選擇集準(zhǔn)確定義了將從操作返回的數(shù)據(jù)。選擇集是 GraphQL 的最大價(jià)值所在——它們?cè)试S客戶端查詢特定的數(shù)據(jù)集并接收包含所請(qǐng)求信息的響應(yīng)：不多不少。
- GET /graphql?query={ books(id:12) { authors { firstName, lastName } title, yearPublished, length }
- {
- Query { // operation type
- books (id:12) { // operation endpoint
- authors { // requested fields
- firstName
- lastName
- }
- title
- yearPublished
- }
- }
- }
有關(guān) GraphQL 規(guī)范的結(jié)構(gòu)和語法的更多信息，請(qǐng)參閱 GraphQL 的文檔。(https://graphql.github.io/graphql-spec/June2018/#sec-Overview)
接下來，我們將看下 GraphQL 中查詢的結(jié)構(gòu)。
6 GraphQL 查詢解析
下面是一個(gè)結(jié)構(gòu)化的 GraphQL 查詢，用于獲取特定書籍的數(shù)據(jù)，包括作者的姓和名
- GET /graphql?query={ books(id:12) { authors { firstName, lastName } title, yearPublished, length }
- {
- Query { // operation type
- books (id:12) { // operation endpoint
- authors { // requested fields
- firstName
- lastName
- }
- title
- yearPublished
- }
- }
- }
這一切都可以通過一個(gè)查詢由 GraphQL 服務(wù)器邏輯解析和處理完成。當(dāng)把它與 REST 架構(gòu)中相同結(jié)構(gòu)的請(qǐng)求進(jìn)行比較時(shí)，GraphQL 的優(yōu)勢(shì)就開始顯現(xiàn)出來了。
讓我們看看下面的 REST 請(qǐng)求結(jié)構(gòu)，然后重點(diǎn)討論其中的一些差異！
7 REST 請(qǐng)求解析
要向 REST API 發(fā)出相同的請(qǐng)求，客戶端首先需要向能夠返回圖書數(shù)據(jù)的端點(diǎn)發(fā)送一個(gè)請(qǐng)求，并將圖書 id 作為參數(shù)傳入：
- GET /books/12
這個(gè)請(qǐng)求可能會(huì)返回一個(gè)包含特定圖書所有數(shù)據(jù)的對(duì)象，例如：
- {
- "title" : "The Hitchhiker's Guide to the Galaxy",
- "authorID": 42,
- "yearPublished" : 1978,
- "length": 208,
- "genre": "Science Fiction"
- }
在我 們的例子里，與相同的 GraphQL 查詢相比，該響應(yīng)有兩個(gè)缺點(diǎn)：
REST 響應(yīng)包含類似 genre 這樣的額外數(shù)據(jù)，返回的信息超出了我們的需求。
REST 需要再發(fā)送一個(gè)請(qǐng)求來獲得我們實(shí)際上正在查找的數(shù)據(jù)：這個(gè)特定作者的所有書籍。
為了獲得這些數(shù)據(jù)，我們需要使用我們的 authorID 發(fā)出一個(gè)額外的請(qǐng)求：
- GET /authors/42
這個(gè)請(qǐng)求的響應(yīng)應(yīng)該包含我們正在查找的所有數(shù)據(jù)：
- {
- "firstName": "Douglas",
- "lastName": "Adams"
- }
現(xiàn)在我們已經(jīng)有了需要的所有書籍和作者數(shù)據(jù)，響應(yīng)解析由客戶端完成。現(xiàn)在，前端應(yīng)用程序必須將來自不同端點(diǎn)的數(shù)據(jù)組合在一起，用于實(shí)現(xiàn)期望的功能?？偟膩碚f，與 REST API 相比，GraphQL 提供的性能優(yōu)勢(shì)可以為前端開發(fā)人員帶來回報(bào)。使用 GraphQL 規(guī)范創(chuàng)建服務(wù)器可能需要更多的設(shè)置以及編寫預(yù)測性的服務(wù)器端邏輯來解析和處理請(qǐng)求。
雖然 GraphQL 的設(shè)置成本可能比傳統(tǒng)的 REST 架構(gòu)要高，但是，更易于維護(hù)的代碼、健壯的開發(fā)工具和精簡的客戶端查詢所帶來的好處通常會(huì)超過成本。
我們?cè)谖⑿派?4小時(shí)期待你的聲音
解答本文疑問/技術(shù)咨詢/運(yùn)營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
微信二維碼
微信二維碼
移動(dòng)版官網(wǎng)