歡迎閱讀 👏前端
本文會經過實際場景介紹一下 GraphQL,目的是讓你快速瞭解 GraphQL 是什麼,以及基本工做思路,不包含實際用法,因此閱讀很輕鬆。程序員
GraphQL 是後端數據查詢語言,能夠簡單理解爲 GraphQL 對標的是 REST 接口。數據庫
GraphQL 由 Facebook 開源,目前已經在 Facebook 中支撐千億級的 API 接口調用,在 Facebook 以外正在被迅速應用。後端
咱們不要被 GraphQL 這個名字誤導了,第一次看見它時,我還覺得這是一個圖數據庫的查詢語言呢。數據結構
GraphQL 大致上的確是 "圖查詢" 的意思,但這個 "圖" 是數據圖譜的意思,不是圖數據庫。性能
以上圖爲例,這是主流的 Feed 流形式,如何實現呢?學習
定下來界面中須要顯示哪些數據元素以後,後端開始爲其定製一個 REST 接口,查詢出相關數據:spa
後端程序員進行數據關聯查詢,取出其中須要的數據項,而後封裝爲一個易於前端操做的數據結構,例如 JSON 對象。設計
這樣 Feed 流的接口就 OK 了,一樣的,對於其餘界面再進行相應的接口開發。3d
例如在帖子詳情頁面,涉及的數據仍是 Feed 流中的這些,但具體的數據項不一樣了,例如:
由於數據項的不一樣,就須要針對這個界面需求從新開發吧。
若是你嫌麻煩,提供了一個大而全的接口,後端開發是簡單了,但新問題來了,例如:
有什麼更好的辦法呢?(若是你有更好的經驗,歡迎發給我,我會分享給你們)
Facebook 爲了解決這個問題,設計出了 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個部分:
comments
、likes
關聯了其餘的數據類型,這樣就描繪出了數據對象之間的關係。而後咱們看前端怎麼用。
上圖中,左邊是前端的調用方式,右邊是返回的數據結果。
前端調用了 recentPosts 接口,並指明瞭只須要返回 id
,因此,返回結果中只有 id 數據項。
上圖中,前端調用了 recentPosts 接口,此次指明瞭須要:
在右邊的返回結果中能夠看到,應前端的需求返回了相應數據。
在以數據圖譜爲中心以後,後端省心了,前端自由了。因此 GraphQL 的核心就是構建好這個數據圖譜。
以上就是 GraphQL 基本內容了,若是對它有興趣,能夠留言告訴我,以後我會整理一個 GraphQL 的使用教程。
歡迎你們關注個人公衆號【風平浪靜如碼】,海量Java相關文章,學習資料都會在裏面更新,整理的資料也會放在裏面。
以爲寫的還不錯的就點個贊,加個關注唄!點關注,不迷路,持續更新!!!