再見 REST，你好 GraphQL
寫過前端的都知道，REST 風格的 API 適合簡單的增刪改查。對于稍微復雜的關聯(lián)查詢，就顯得不太合適：如果設計一個 REST 接口，一般情況下會返回關聯(lián)表的全部字段，以滿足更多類似的查詢需求，如果設計多個細粒度接口，前端就需要查詢很多次，自己拼裝數據。粗粒度的接口導致不必要的數據傳輸，細粒度的接口導致函數爆炸，你見過 JavaScript 的 Promise 滿天飛吧。
在此情景下 Facebook 的工程師于 2015 年開源了 GraphQL 規(guī)范，讓前端自己描述自己希望的數據形式，服務端則返回前端所描述的數據結構。簡單的來說，前端要啥，后端就返回啥，非常靈活。
什么是 GraphQL?
簡單來說，GraphQL 是一種面向數據的 API 查詢風格，把所有數據都視為已連接的圖形，客戶端能夠準確地獲得它需要的數據，沒有任何冗余，也讓 API 更容易地隨著時間推移而演進，還能用于構建強大的開發(fā)者工具。
比如，前端只需要 hero 的 name，那么后端就只返回這個 name，沒有冗余：
再比如：前端需要顯示作者的帖子信息，作者本人的信息，作者的關注者列表，假如是 REST，前端需要請求這三個接口，再組裝：
- /user/
獲取用戶(作者)詳細信息，可能是名稱。 - /user/
/posts 獲取該用戶發(fā)布的帖子列表。 - /user/
/followers 獲取用戶的關注者列表。
現在我們可以通過 GraphQL 的一次查詢拿到全部信息，無需從好幾個異步 API 里面來回找：
- query {
- User(id: '123') {
- name
- posts {
- title
- }
- followers {
- name
- }
- }
- }
簡潔明了，不是嗎?
GraphQL 帶來的改變
目前應用開發(fā)的主流就是前后端分離，前后端只通過 API 來交流，結構大概如下圖：
如果使用 GraphQL，那么后端將不再生產 API，而是將 Controller 層維護為 Resolver，和前端約定一套 Schema，這個 Schema 將用來生成接口文檔，前端直接通過 Schema 或生成的接口文檔來進行自己期望的請求。
經過幾年一線開發(fā)者的填坑，已經有一些不錯的awesome-graphql(https://github.com/chentsulin/awesome-graphql)用于開發(fā)與生產，很多語言也提供了對 GraphQL 的支持，比如 JavaScript/Nodejs、Java、PHP、Ruby、Python、Go、C# 等。
GraphQL 的使用趨勢
一些比較有名的公司正在轉換 REST API 到 GraphQL，比如 Twitter、IBM、Coursera、Airbnb、Facebook、Github、攜程等，特別是 Github，它的 v4 版外部 API 只使用 GraphQL。據一位在 Twitter 工作的大佬說硅谷不少一線二線的公司都在想辦法轉到 GraphQL 上，但是同時也說了 GraphQL 還需要時間發(fā)展，因為將它使用到生產環(huán)境需要前后端大量的重構，這無疑需要高層的推動和決心。
GraphQL 的局限性
對于簡單的應用程序而言，設置類型、查詢等可能會有些復雜，相比之下 REST 可以更輕松完成。
對于復雜的查詢，GraphQL 只需要一次接口請求，這樣雖然網絡層面的請求數被優(yōu)化了，但是數據庫層面的查詢可一點都不少，數據庫查詢可能會成為性能瓶頸，還有很大的優(yōu)化空間。
GraphQL 的優(yōu)勢
檢索精確的數據，沒有冗余。通常，當數據需求發(fā)生變化時，您只需要修改查詢，并且不需要太多更改，從而提高前后端的開發(fā)效率，可以快速進行產品迭代。
最后的話
GraphQL 已經被各種體量的團隊所使用，在不同的環(huán)境、不同的語言下，用于增強移動應用、網站和 API。如果你已經厭倦了 REST API，現在是時候學習一下 GraphQL 了。關注公眾號「Python七號」，學習更多技術干貨。
