自從 2015 年 Facebook 開源 GraphQL 規(guī)范以來，它就在前端 Web 開發(fā)中迅速流行起來,。

1. 為什么這種新技術(shù)會突然流行起來,？

2. 與傳統(tǒng) REST API 相比，GraphQL 提供了哪些優(yōu)勢,？

我們將討論 GraphQL 的設計原則,，比較 GraphQL 與 REST 中的相同請求，并深入探討 GraphQL 相對其他架構(gòu)的優(yōu)點,。

為理解 GraphQL 作為 API 架構(gòu)的好處,，我們要討論 API 在客戶端 - 服務器結(jié)構(gòu)中的作用。API（應用程序編程接口）是一個中間層,，它允許服務器從客戶端接收結(jié)構(gòu)化數(shù)據(jù)請求,，并針對請求的數(shù)據(jù)發(fā)送結(jié)構(gòu)化的響應。設計 API 架構(gòu)的方法有很多種,。

讓我們來研究一下促使 GraphQL 適合現(xiàn)代化 Web 應用程序的重要基本設計原則,。

GraphQL 規(guī)范概括了 5 個設計原則，這使其成為現(xiàn)代前端開發(fā)的良好解決方案。我們看一下 GraphQL 的設計原則,，并以 Facebook 新聞推送作為我們的用例,。

1. 查詢?yōu)榉謱咏Y(jié)構(gòu)，使用將查詢與響應數(shù)據(jù)1對1匹配的分層和嵌套字段格式,。查詢和響應的形狀類似于樹,，可查詢每個項的其他嵌套字段。在 Facebook 的新聞推送中,，這種結(jié)構(gòu)允許一個查詢返回一個帖子列表,、每個特定帖子的評論，以及每個評論的點贊,。

2. 該結(jié)構(gòu)以產(chǎn)品為中心,，關(guān)注前端希望如何接收數(shù)據(jù)，并構(gòu)建交付所需的運行時,。這使得 Facebook 的新聞推送可通過一次請求從后端獲取需要的所有數(shù)據(jù),，使服務器按照 GraphQL 的規(guī)范從不同的端點獲取數(shù)據(jù)。

3. 它使用特定于應用程序的類型系統(tǒng),，該系統(tǒng)使開發(fā)人員能在執(zhí)行前確保查詢使用了有效類型,，并且語法正確。例如,，新聞推送的 GraphQL 模式要求字段“user”必須包含一個字符串,，而“l(fā)ikes”必須包含一個數(shù)字。如果查詢試圖添加不同類型的輸入,，GraphQL 將在執(zhí)行查詢前拋出一個錯誤,。

4. GraphQL 查詢是在客戶端指定的，因此,，客戶端確切知道它將以何種格式接收數(shù)據(jù),。這意味著，如果前端請求的格式是包含用戶名,、評論和點贊的 post 數(shù)據(jù),，那么來自 Facebook 新聞推送的請求會構(gòu)建在一個對象中，而不是像其他架構(gòu)那樣構(gòu)建多個單獨的數(shù)據(jù)塊,。

5. 使用 GraphQL 的服務器結(jié)構(gòu)必須是內(nèi)省的,，或者可由 GraphQL 自己查詢。于是才有了像 GraphiQL 或 GraphQL playground 這樣的強大工具,。這兩種工具都可以讓 Facebook 開發(fā)人員準確地看到在他們的服務器上使用了哪些查詢和字段,。

為討論向 GraphQL 的轉(zhuǎn)變，以及這些設計原則如何給開發(fā)帶來好處,。

我們首先深入了解傳統(tǒng)的 REST API 架構(gòu)和它的不足之處,。

REST 架構(gòu)的設計范式側(cè)重于分配 HTTP 請求方法（GET,、POST、PUT,、PATCH,、DELETE）和 URL 端點之間的關(guān)系。

在 REST 架構(gòu)中,，方法和端點的每個組合得到不同的封裝功能,。如果客戶端需要的數(shù)據(jù)特定端點 / 方法不提供，則可能需要額外請求,。從 REST 請求返回的數(shù)據(jù)格式依賴于端點—不能保證這些數(shù)據(jù)會按照前端需要的方式進行格式化,。為使用來自響應的數(shù)據(jù)（格式與缺省情況下從端點返回的格式不同）,，必須在客戶端編寫數(shù)據(jù)解析和數(shù)據(jù)操作,。

接下來，讓我們看看 GraphQL 規(guī)范與 REST 的不同之處,，以及它的優(yōu)點,。這些優(yōu)點使這個新架構(gòu)成為特別適合解決客戶端和服務器之間數(shù)據(jù)交付問題的解決方案。

與 RESTful API 一樣,，GraphQL API 設計用于處理 HTTP 請求并對這些請求提供響應,。無論如何，這就是相似之處,。REST API 構(gòu)建在請求方法和端點之間的連接上,，而 GraphQL API 被設計為只通過一個端點，始終使用 POST 請求進行查詢,，其 URL 通常是 yourdomain.com/graphql,。

請求到達 GraphQL 端點后，客戶端請求的載荷完全在請求體中處理,。這個請求體必須遵循 GraphQL 規(guī)范,，API 必須有適當?shù)姆掌鞫诉壿媮硖幚磉@些請求并提供適當?shù)捻憫?/p>

這提供了比 RESTful API 更流暢的客戶端體驗，后者可能要求客戶端針對多個數(shù)據(jù)塊發(fā)出多個請求,，并在數(shù)據(jù)返回后進行操作,。

為了闡明 GraphQL 是如何實現(xiàn)這一點的，讓我們分解一下 GraphQL 服務器的結(jié)構(gòu),。

啟用 GraphQL 邏輯的服務器端邏輯由定義了服務器功能的 Documents 組成,。這些 Documents 包含可執(zhí)行文件和類型系統(tǒng)定義。顧名思義,，類型系統(tǒng)定義為每個數(shù)據(jù)字段定義可接受的類型和格式輸入及結(jié)果,。

可執(zhí)行文件包含要處理的可能的操作列表，其中包括操作類型（查詢,、修改或訂閱）,、操作名稱、要查詢或?qū)懭氲淖侄魏鸵粋€選擇集，該選擇集準確定義了將從操作返回的數(shù)據(jù),。選擇集是 GraphQL 的最大價值所在——它們允許客戶端查詢特定的數(shù)據(jù)集并接收包含所請求信息的響應：不多不少,。

有關(guān) GraphQL 規(guī)范的結(jié)構(gòu)和語法的更多信息，請參閱 GraphQL 的文檔,。(https://graphql./graphql-spec/June2018/#sec-Overview)

接下來,，我們將看下 GraphQL 中查詢的結(jié)構(gòu)。

下面是一個結(jié)構(gòu)化的 GraphQL 查詢,，用于獲取特定書籍的數(shù)據(jù),，包括作者的姓和名

這一切都可以通過一個查詢由 GraphQL 服務器邏輯解析和處理完成。當把它與 REST 架構(gòu)中相同結(jié)構(gòu)的請求進行比較時,，GraphQL 的優(yōu)勢就開始顯現(xiàn)出來了,。

讓我們看看下面的 REST 請求結(jié)構(gòu)，然后重點討論其中的一些差異,！

要向 REST API 發(fā)出相同的請求,，客戶端首先需要向能夠返回圖書數(shù)據(jù)的端點發(fā)送一個請求，并將圖書 id 作為參數(shù)傳入：

這個請求可能會返回一個包含特定圖書所有數(shù)據(jù)的對象,，例如：

在我們的例子里,，與相同的 GraphQL 查詢相比，該響應有兩個缺點：

1. REST 響應包含類似 genre 這樣的額外數(shù)據(jù),，返回的信息超出了我們的需求,。

2. REST 需要再發(fā)送一個請求來獲得我們實際上正在查找的數(shù)據(jù)：這個特定作者的所有書籍。

為了獲得這些數(shù)據(jù),，我們需要使用我們的 authorID 發(fā)出一個額外的請求：

這個請求的響應應該包含我們正在查找的所有數(shù)據(jù)：

現(xiàn)在我們已經(jīng)有了需要的所有書籍和作者數(shù)據(jù),，響應解析由客戶端完成。現(xiàn)在,，前端應用程序必須將來自不同端點的數(shù)據(jù)組合在一起,，用于實現(xiàn)期望的功能。總的來說,，與 REST API 相比,，GraphQL 提供的性能優(yōu)勢可以為前端開發(fā)人員帶來回報。使用 GraphQL 規(guī)范創(chuàng)建服務器可能需要更多的設置以及編寫預測性的服務器端邏輯來解析和處理請求,。

雖然 GraphQL 的設置成本可能比傳統(tǒng)的 REST 架構(gòu)要高,，但是，更易于維護的代碼,、健壯的開發(fā)工具和精簡的客戶端查詢所帶來的好處通常會超過成本,。