歡迎閱讀 ?
本文會通過實際場景介紹一下 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相關文章，學習資料都會在裡面更新，整理的資料也會放在裡面。
覺得寫的還不錯的就點個贊，加個關注唄！點關注，不迷路，持續更新！！！