用了6個月的GraphQL，真香！

雲栖号資訊：【 點選檢視更多行業資訊

】

在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！

本文作者用 GraphQL 在後端做了 6 個月的項目，分享了自己體驗 GraphQL 的優點和缺點。作者認為 GraphQL 提供的靈活性讓其缺點不足為道，強烈建議使用 GraphQL 作為 REST API 的替代品。

GraphQL 是一種用于 API 的查詢語言，同時基于你的現有資料來執行這些查詢的服務端運作時。它為 API 中的資料提供了一套易于了解的完整描述，并讓用戶端能準确地獲得它們所需的查詢内容，且不會附帶任何備援資訊。

最初，GraphQL 隻是 Facebook 為其移動 APP 開發的内部解決方案，後來向社群開源。

1.優點

實用的資料交換

使用 GraphQL 時，開發者可以根據用戶端需要的字段對查詢進行靈活定義，這種“量體裁衣式”的自定義非常實用，而且執行起來十分簡單。如果前端需要一個人的“名字”和“年齡”，GraphQL 就能隻對這兩個字段進行查詢。而這個人的“姓”和“位址”就不會在該查詢的響應中被發送。

使用資料加載器來減少網絡調用

盡管 GraphQL 庫本身并不包含資料加載器（Dataloader），但是資料加載器的确是一個非常實用的程式庫，可以用來解耦你的 APP 中互不相關的部分，還不會犧牲批處理資料加載的性能。雖然資料加載器提供了一個加載單個值的 API，但所有并發請求将被組合起來并送出給你的批處理加載函數。這就能讓你的 APP 在整個應用程式中安全地執行分布式資料擷取。

舉個例子：在上述例子的基礎上，這次我們從另一個叫做“交易服務”的服務中擷取一個“人”的“銀行資訊”，這時後端可以從“交易服務”中擷取相關的“銀行資訊”，然後将這個結果與這個“人”的“名字”和“年齡”捆綁在一起，再将這些資訊資源作為響應發送回去。

在公開資料和資料庫模型之間進行解耦

GraphQL 的一大優點是能以解耦的方式将資料庫模組化資料對使用者進行選擇性地公開。這樣，在對持久層（persistence layer）進行設計時，我們可以在聚焦于該層需求的同時，兼顧考慮怎樣才是向外部世界公開資料的最佳方式。該功能還能與資料加載器聯合起來使用，因為你可以在将資料發送給使用者前将這些資料組合在一起，這樣一來為公開資料設計模型就會變得非常容易。

擺脫 API 版本控制的煩惱

API 版本控制是一個經常遇到的問題。一般而言，通過在相同的 API 前面添加一個 v2 标簽來添加一個新版本去解決這個問題，這是相當簡單的解決方案。但使用 GraphQL 時，情況就大不相同了，盡管你還是可以使用上述解決方案來處理這個問題，但這并不符合 GraphQL 的自由精神。GraphQL 文檔明确指出，你應該更新你的 API，這意味着在不破壞原 API 的情況下向現有端點添加更多字段。前端仍然可以使用相同的 API 進行查詢，并且在需要時請求新字段。就是這麼簡單。

這個特性在與前端開發團隊協作時非常有用。由于設計更改，前端團隊可以請求添加所需要的新字段，而後端團隊能輕松地實作該字段的添加，且不會擾亂現有API。

前後端團隊獨立開發

使用 GraphQL，前端和後端團隊能彼此獨立地工作。由于 GraphQL 包含嚴格類型定義的 schema，前後端團隊可以互不幹擾地并行工作。

首先，前端團隊甚至在無需檢視代碼的情況下，就能很容易地從後端生成 schema。而這個生成的 schema 可以直接用于查詢的建立。

其次，前端團隊還可以一直使用 API 的 mock 版本進行開發工作。他們還能用 mock 版本來測試代碼。這為開發人員提供了相當令人愉悅的體驗，且完全不會對他們的開發工作造成任何妨礙。

2.缺點

并不是所有的 API 都可以更新

有時，由于來自業務或設計的變化日積月累，迫使 API 的實作需要完全更改。在這種情況下，你将不得不依賴舊的方法來進行 API 版本控制。

難維護的代碼

我遇到過好幾次，在使用資料加載器擷取資料時，代碼有時會分散到多個地方，這對代碼的維護帶來一些困難。

響應時間長

由于查詢可以不斷更新并變得非常龐大，這有時會影響查詢的響應時間。要避免這種情況，請確定讓響應資源保持簡潔。這方面的指南，請檢視 Github GraphQL API。

https://developer.github.com/v4/

緩存困難

通常對一個 API 響應進行緩存的主要目的是能更快地從未來的請求中獲得響應。與 GraphQL 不同，REST API 所利用的是将緩存内置于 HTTP 技術規範中。正如前面提到的，一個 GraphQL 查詢可以請求資源的任何字段，這就使得在 GraphQL 裡使用緩存天生就很困難。

3.結論

我個人強烈推薦使用 GraphQL 作為 REST API 的替代品。GraphQL 所提供的極大靈活性讓它的缺點瑕不掩瑜。當然這裡提到的優點和缺點可能并不總是适用于所有應用場景，但是值得在決定是否使用 GraphQL 時納入考慮，希望我所提供的這些意見能對你的項目有所幫助。

【雲栖号線上課堂】每天都有産品技術專家分享！

課程位址：

https://yqh.aliyun.com/zhibo

立即加入社群，與專家面對面，及時了解課程最新動态！

【雲栖号線上課堂 社群】

https://c.tb.cn/F3.Z8gvnK

原文釋出時間：2020-06-14

本文作者：Manish Jain

本文來自：“

InfoQ

”，了解相關資訊可以關注“

”