這個指南教你在不修改任何代碼的情況下，完成從 REST 到 GraphQL 的遷移。這樣，GraphQL 就能讓你的 REST 真正休息一下了！
從 REST 到 GraphQL
GraphQL 的支持者在宣傳推廣 GraphQL 方面已經做得非常好了。出於對他們努力的尊重，我就不再深入介紹細節，只是稍微總結一下：
- GraphQL 允許我們在單個請求中獲取多個資源；
- 通過精確描述所需數據，GraphQL 解決了 REST 過度抓取數據的問題；
- GraphQL 藉助在一個請求中獲取相關的數據，解決了前端 N+1 查詢的問題。
本指南中，我會介紹大多數倡導 GraphQL 的人所忽略的一個點，就是“我們在 REST 上有了巨大投入”。這意味著：
- 我們大多數的服務都是基於 REST 的；
- 我們更願意編寫 REST 服務；
- 我們希望支持使用 REST API 的現有客戶端。
雖然有許多文章幫我們從 REST 遷移到 GraphQL，但這些做法都迫使我們更改現有的代碼庫或在 REST 服務前面編寫新的代碼庫。
但是，稍等一下……
如果它還能運行，就別去碰它。
這難道不是編程的第一規則嗎？
遷移可能非常痛苦，尤其是面對巨大的代碼庫時，更會令人望而生畏。隨時存在將已有功能破壞掉的可能性。
我們為什麼不能繼續保持 REST 呢？我們天性懶惰，都喜歡用簡單的技巧和容易的解決方案。
如果有一種方式，讓我們原樣保持 REST 服務，且無需任何代碼變更就能在其之上實現一個 GraphQL 層，那會怎樣？聽起來很神奇， Space Cloud 就能幫我們實現這一切
Space Cloud 是什麼？
簡而言之，Space Cloud 是一個開源的 Web 服務器，它能在數據庫和微服務之上即時提供 GraphQL 和 REST API。
Space Cloud 最酷的一點在於，所有 API 都是實時的。我們可以選擇訂閱數據庫的變更。在實現實時應用時，該功能非常便利。
本指南中，我們會用 Space Cloud 的 remote service 模塊將 REST 服務遷移成 GraphQL。
架構
基於 REST 之上的 GraphQL 架構最終如下圖所示：
我們的應用將會發起對 Space Cloud 的 GraphQL 查詢，該請求又會訪問服務器上的 REST 端點。在該場景中，Space Cloud 會作為 GraphQL 代理或 API 網關。
你可能注意到，Space Cloud 是一個單獨的 GraphQL 層，位於 REST 服務之上。這種方式的優點在於 REST 服務依然能夠保持原樣，已有的客戶端可以直接使用它們。這樣，從 REST 服務遷移至 GraphQL 不會破壞舊的客戶端。
接下來，讓我們開始。
我們將要構建什麼？
本指南中，我們將會構建一個簡單的算數服務，它包含如下端點：
求和計算端點：POST /adder
翻倍計算端點：GET /doubler/:num
求和計算端點將會返回兩個數的和，這兩個數是通過請求的 body 獲取到的。翻倍計算端點將會對其接收到的值翻倍，初始值是通過 URL 路徑參數獲取到的。
現在，開始構建
閱讀更多 InfoQ 的文章
