[譯] Medium 的 GraphQL 服務設計

• 原文地址：GraphQL Server Design @ Medium
• 原文做者：Sasha Solomon
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：EmilyQiRabbit
• 校對者：KarthusLorin，weibinzhu

Medium 的 GraphQL 服務設計

前一段時間，咱們已經介紹了如何使用 GraphQL 將項目遷移爲 React.js 和麪向服務的結構。如今，咱們想要介紹 GraphQL 服務結構是如何幫助咱們更加平滑順利地完成遷移的。

在開始設計 GraphQL 服務以前，咱們必需要牢記三件事情：

方便修改數據格式 目前咱們使用協議緩衝區 protocol buffers 來做爲來自後端的數據模型 schema。可是，咱們使用數據的方式會變化，而協議緩衝卻沒有跟進。這就意味着咱們的數據格式並不老是客戶端須要的那樣。

清楚地區分哪些數據是用於客戶端的 在 GraphQL 服務中，被傳遞的數據都處於客戶端的「準備就緒」的不一樣階段。咱們應當讓每一個準備就緒的狀態更加清晰，而不是把它們混合起來，這樣咱們就能確切的知道那些數據是用於客戶端的。

方便添加新的數據源 既然咱們要轉型爲面向服務的結構，咱們就但願確保爲 GraphQL 服務添加新的數據源是很容易的，同時明確數據來源。

牢記這些，咱們就能夠構造出一個有三種不一樣角色的服務框架：

獲取器 Fetchers、存儲庫（Repos）和 GraphQL 模式。

責任分層塊

每一層都有本身的職責，而且只與它的上層交互。讓咱們來談談每一層都具體作了什麼。

獲取器 Fetchers

從任意數量的源獲取數據

獲取器的目的是爲了從數據源獲取數據。GraphQL 服務獲取的數據應該已經完成了業務邏輯的添加或更改。

獲取器應該與 REST 或 gRPC 端口相對應。獲取器須要一個協議緩衝區 protobuf。這意味着由獲取器獲取的任何數據都必須遵循協議緩衝區定義的模式。

存儲庫

根據客戶端須要設計數據

GraphQL 模型用存儲庫來作數據倉庫。存儲庫「存儲」了來自數據源的已處理過的數據。

在這一步，咱們能夠打包或展開字段和對象、移動數據，等等，將數據轉化爲客戶端須要的格式。

從遺留的系統轉型，這一步是必須的，由於它給了咱們爲客戶端更新數據格式的自由，同時不用更新或者添加接口和相應的協議緩衝區。

存儲庫僅從獲取器獲取數據，實際上從不本身請求外界數據。換句話說，存儲庫只建立咱們須要的數據格式，可是它們並不「知道」數據是從哪裏獲取的。

GraphQL 模型

從存儲庫對象派生出客戶端模型

GraphQL 模型是是數據發送到客戶端的時候選取的格式。

GraphQL 模型僅使用存儲庫的數據，從不會直接和獲取器交互。這使得咱們可以清楚地將關注點分離開。

另外，GraphQL 模型是徹底從存儲庫模型派生出來的。模型徹底不會改變數據，它也並不須要：存儲庫已經將數據轉化爲咱們須要的格式，因此模型只須要使用數據便可。這樣，關於數據格式是什麼樣的或者是咱們能夠在哪裏操做數據格式，就沒有可混淆的了。

GraphQL 服務數據流

數據是如何在 GraphQL 服務中流動的

當數據經過不一樣的層時，它的格式都會變得更像客戶端所須要的。每一步的數據來自哪裏是很清楚的，咱們也知道服務的每一部分都負責什麼。

這些抽象邊界意味着，咱們能夠經過替換不一樣的數據源增量地遷移遺留系統，但無需重寫整個系統。這使咱們的遷移方法清晰且易於遵循，同時在不當即更改全部內容的狀況下，能夠輕鬆地朝着面向服務的體系結構完成工做。

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。