[譯] 怎樣使用GraphQL - 4.大局(架構)

英文原版地址：https://www.howtographql.com/...

GraphQL僅僅做爲規範發佈。 這意味着GraphQL實際上，不會是一個詳細描述GraphQL服務端行爲的完整文檔。

若是你想使用GraphQL，你必須本身去搭建GraphQL服務。你能夠選擇任何編程語言來實現（例如這些可參考的實現方式）或經過選用像Graphcool這樣的服務，它提供了一個功能強大的GraphQL API。

用例

在本節中，咱們將介紹使用GraphQL服務的3種不一樣類型的架構：

1.鏈接數據庫的GraphQL服務

2.GraphQL服務做爲輕量的一層，在第三方接口，或一些現有系統之上。經過一個GraphQL API集成起來。

3.混合以上兩種方式，經過相同的GraphQL API，同時能夠訪問數據庫和第三方接口或現有舊系統。

上述這三種架構，表明了GraphQL的主要用例，並展示出了使用時的靈活性。

1.鏈接數據庫的GraphQL服務

這種架構是greenfield項目中最多見的。在設置中，您有一個（Web）服務器實現GraphQL規範。 當查詢請求到GraphQL服務器時，服務器讀取查詢的payload並從數據庫中讀取所需的信息。 這被稱爲查詢的解析。而後，它按照官方規範中的描述構造響應對象，並將其返回給客戶端。

須要注意的是，GraphQL其實是傳輸層無關的。這意味着它能夠和任意的網絡協議一塊兒使用。 所以，GraphQL服務器多是基於TCP，Websockets或者其餘網絡協議的。

GraphQL也不關心是什麼數據庫以及用於存儲數據的格式。你可使用像AWS Aurora這樣的SQL數據庫或者像MongoDB這樣的NoSQL數據庫。

一個標準的鏈接到單個數據庫的，GraphQL服務器的greenfield架構。

2.集成現有系統的GraphQL層

GraphQL的另外一個主要用例是將多個現有系統集成在一個統一的GraphQL API後面。這對有着遺留基礎設施和許多不一樣API的公司尤爲引人注目，這些API已經維護了多年，如今卻形成了很重的維護負擔。這些傳統系統的一個主要問題是，人們很難作出須要訪問多箇舊系統的創新產品。

在這種狀況下，GraphQL能夠用於統一這些系統，並將這些複雜的事情隱藏在一個友好的GraphQL API以後。這樣，就能夠去開發新的客戶端應用，只需與GraphQL服務器通訊便可獲取所需的數據。而後，GraphQL服務器負責從現有系統中提取數據，並以GraphQL格式進行響應。

就像在之前的架構中，GraphQL服務器不關心正在使用的數據庫的類型，這一次它不關心用來獲取查詢結果所需的數據源。

GraphQL容許你隱藏現有系統的複雜性，在統一的GraphQL接口後面，集成微服務，傳統基礎架構和第三方API。

3.鏈接數據庫與現有系統集成的混合方式

最後，能夠組合這兩種方法，構建一個鏈接數據庫，同時又與舊有或第三方系統集成的GraphQL服務器。

當服務器接收到查詢時，將解析它，並從鏈接的數據庫或某些集成的API中檢索出所需的數據。

這兩種方法也能夠組合起來，GraphQL服務器能夠從單個數據庫或者現有系統獲取數據，從而達到靈活性，並將全部數據管理的複雜性交給到服務器。

Resolver方法

可是，如何經過GraphQL得到這種靈活性？它是如何適配好這些差異明顯的不一樣類型的用例？

如上一章所瞭解，GraphQL查詢（或mutation）的payload由一組字段組成。在GraphQL服務器實現中，這些字段中的每個實際上都對應於一個稱爲resolver的函數。resolver的做用就是獲取對應字段的數據。

當服務端收到查詢時，會調用查詢中payload裏字段對應的函數，檢索出每一個字段的數據。當全部resolver都返回告終果，服務端將按照查詢裏描述的數據格式打包好數據，將結果返回給客戶端。

查詢中的每一個字段對應一個resolver函數。當須要查詢指定數據時，GraphQL將調用全部須要的resolver方法。

GraphQL客戶端庫

GraphQL對於前端開發人員來講特別好，由於它徹底消除了REST API的許多不便和缺點，例如過分和欠缺的數據加載。複雜性被推到服務端，強大的服務器能夠處理繁重的計算工做。客戶端沒必要知道獲取的數據實際來自哪裏，只須要使用單一，一致且靈活的API就能夠。

讓咱們考慮使用GraphQL引入的重大變化，從一個至關迫切的數據獲取方法轉變爲一個純粹的聲明式方法。從REST API獲取數據時，大多數應用必須執行如下步驟：

1.構造和發送HTTP請求（例如，在Javascript中fetch）
2.接收並解析服務器響應
3.在本地存儲數據（簡單地存在內存或持久存儲）
4.在UI中顯示數據

使用理想化的聲明式數據獲取方法，客戶端不該該作如下兩個步驟：

1.描述數據要求
2.在UI中顯示數據

全部底層網絡任務以及數據存儲都應該被抽象出來，數據依賴關係的聲明才應該是主要部分。

這偏偏是GraphQL的客戶端庫，如Relay或Apollo能作到的。它們提供了重要部分的抽象，讓你沒必要去重複執行基礎方法。從而讓你可以專一於應用自己。