歡迎閱讀 👏
本文會通過實際場景介紹一下 GraphQL，目的是讓你快速了解 GraphQL 是什么，以及基本工作思路，不包含實際用法，所以閱讀很輕松。
一、GraphQL 是什么？
GraphQL 是后端數據查詢語言，可以簡單理解為 GraphQL 對標的是 REST 接口。
GraphQL 由 Facebook 開源，目前已經在 Facebook 中支撐千億級的 API 接口調用，在 Facebook 之外正在被迅速應用。
我們不要被 GraphQL 這個名字誤導了，第一次看見它時，我還以為這是一個圖數據庫的查詢語言呢。
GraphQL 大體上的確是 "圖查詢" 的意思，但這個 "圖" 是數據圖譜的意思，不是圖數據庫。
二、GraphQL 思路
以上圖為例，這是主流的 Feed 流形式，如何實現呢？
定下來界面中需要顯示哪些數據元素之后，后端開始為其定制一個 REST 接口，查詢出相關數據：
- Post 帖子
- 作者
- Like 喜歡
- Comment 評論
- Share 分享
后端程序員進行數據關聯查詢，取出其中需要的數據項，然后封裝為一個易於前端操作的數據結構，例如 JSON 對象。
這樣 Feed 流的接口就 OK 了，同樣的，對於其他界面再進行相應的接口開發。
例如在帖子詳情頁面，涉及的數據還是 Feed 流中的這些，但具體的數據項不同了，例如：
- 帖子需要全文
- Like 需要點贊用戶的圖像列表、ID
- Comment 評論需要詳情列表
因為數據項的不同，就需要針對這個界面需求重新開發吧。
如果你嫌麻煩，提供了一個大而全的接口，后端開發是簡單了，但新問題來了，例如：
- 前端開發需要從結果數據中仔細挑出自己所需要的數據項。
- 接口返回數據中包含大量的前端無用數據，會占用更多的帶寬，影響性能，例如 Facebook 那種千億級的 API 調用量，這種帶寬的浪費是不能容忍的。
有什么更好的辦法呢？（如果你有更好的經驗，歡迎發給我，我會分享給大家）
Facebook 為了解決這個問題，設計出了 GraphQL。
GraphQL 解決思路
對於上述場景，本質上是后端在應付前端的每個需求，是以前端需求為中心。
前端說我要這些數據，后端就去准備這些數據，來一個需求就處理一個需求。
Facebook 的想法是：
數據就是那樣的，每個數據對象包含哪些項，根據各個數據對象的關系就可以形成數據的圖譜了。
后端負責構造這個數據圖譜，前端根據數據圖譜來查詢自己所需要的數據。
這樣前端與后端都是以數據圖譜為中心了，后端就不用伺候前端各種不同類型的需求了，前端也可以自由的精准查詢數據了。
感覺比較抽象是吧，看下面的示例代碼：
# ----------- 定義數據類型 -----------
type Post {
id: String!
title: String!
description: String
comments: [Comment]
likes:[Like]
}
type Comment{
id:String
}
type Like{
id:String
}
# ----------- 定義查詢接口 -----------
type Query {
recentPosts(count: Int, offset: Int): [Post]!
}
type Mutation {
writePost(title: String!, category: String) : Post!
}
（上面代碼可橫向滑動）
其中分為2個部分：
- 上面部分定義了數據類型，例如 Post，指明包含哪些數據項，其中的
comments、likes關聯了其他的數據類型，這樣就描繪出了數據對象之間的關系。 - 下面部分定義了查詢接口，供前端調用。
然后我們看前端怎么用。
上圖中，左邊是前端的調用方式，右邊是返回的數據結果。
前端調用了 recentPosts 接口，並指明了只需要返回 id，所以，返回結果中只有 id 數據項。
上圖中，前端調用了 recentPosts 接口，這次指明了需要：
- Post 的 id 項
- likes 的 id 項
- comments 的 id 項
在右邊的返回結果中可以看到，應前端的需求返回了相應數據。
三、小結
在以數據圖譜為中心之后，后端省心了，前端自由了。所以 GraphQL 的核心就是構建好這個數據圖譜。
以上就是 GraphQL 基本內容了，如果對它有興趣，可以留言告訴我，之后我會整理一個 GraphQL 的使用教程。
寫在最后
歡迎大家關注我的公眾號【風平浪靜如碼】，海量Java相關文章，學習資料都會在里面更新，整理的資料也會放在里面。
覺得寫的還不錯的就點個贊，加個關注唄！點關注，不迷路，持續更新！！！