三分鐘快速解析GraphQL基本工作思路！

風平浪靜如碼發表於2020-11-11

歡迎閱讀 ?

本文會通過實際場景介紹一下 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個部分：