• 原文地址：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、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。