本文首先介紹了 GraphQL，再通過 MongoDB + graphql + graph-pack 的組合實戰應用 GraphQL，詳細介紹瞭如何使用 GraphQL 來進行增刪改查和數據訂閱推送，並附有使用示例，邊用邊學印象深刻~
如果希望將 GraphQL 應用到前後端分離的生產環境，請期待後續文章。
1. 概述
前端的開發隨着 SPA 框架全面普及，組件化開發也隨之成爲大勢所趨，各個組件分別管理着各自的狀態，組件化給前端仔帶來便利的同時也帶來了一些煩惱。比如，組件需要負責把異步請求的狀態分發給子組件或通知給父組件，這個過程中，由組件間通信帶來的結構複雜度、來源不明的數據源、不知從何訂閱的數據響應會使得數據流變得雜亂無章，也使得代碼可讀性變差，以及可維護性的降低，爲以後項目的迭代帶來極大困難。
試想一下你都開發完了，產品告訴你要大改一番，從接口到組件結構都得改，後端也罵罵咧咧不願配合讓你從好幾個 API 裏取數據自己組合，這酸爽 😅
在一些產品鏈複雜的場景，後端需要提供對應 WebApp、WebPC、APP、小程序、快應用等各端 API，此時 API 的粒度大小就顯得格外重要，粗粒度會導致移動端不必要的流量損耗，細粒度則會造成函數爆炸 (Function Explosion)；在此情景下 Facebook 的工程師於 2015 年開源了 GraphQL 規範，讓客戶端自己描述自己希望的數據形式，服務端則返回客戶端所描述的數據結構。
簡單使用可以參照下面這個圖：
比如前端希望返回一個 ID 爲 233 的用戶的名稱和性別，並查找這個用戶的前十個僱員的名字和 Email，再找到這個人父親的電話，和這個父親的狗的名字（別問我爲什麼有這麼奇怪的查找 🤪），那麼我們可以通過 GraphQL 的一次 query 拿到全部信息，無需從好幾個異步 API 裏面來回找：
query {
user (id : "233") {
name
gender
employee (first: 10) {
name
email
}
father {
telephone
dog {
name
}
}
}
}返回的數據格式則剛好是前端提供的數據格式，一分不多，是不是心動了 😏
2. 幾個重要概念
這裏介紹幾個對理解 GraphQL 比較重要的概念，其他類似於指令、聯合類型、內聯片段等更復雜的用法，參考一下 GraphQL 官網文檔 ~
2.1 操作類型 Operation Type
GraphQL 的操作類型可以是 query、mutation 或 subscription，描述了客戶端希望進行什麼樣的操作
- query 查詢：獲取數據，比如查找，CRUD 中的 R
- mutation 變更：對數據進行變更，比如增加、刪除、修改，CRUD 中的 CUD
- substription 訂閱：當數據發生更改，進行消息推送
這些操作類型都將在後文實際用到，比如這裏進行一個查詢操作
query {
user { id }
}2.2 對象類型和標量類型 Object Type & Scalar Type
如果一個 GraphQL 服務接受到了一個 query，那麼這個 query 將從 Root Query 開始查找，找到對象類型（Object Type）時則使用它的解析函數 (Resolver) 來獲取內容，如果返回的是對象類型則繼續使用解析函數獲取內容，如果返回的是標量類型（Scalar Type）則結束獲取，直到找到最後一個標量類型。
- 對象類型：用戶在 schema 中定義的
type - 標量類型：GraphQL 中內置有一些標量類型
String、Int、Float、Boolean、ID，用戶也可以定義自己的標量類型
比如在 Schema 中聲明
type User {
name: String!
age: Int
}這個 User 對象類型有兩個字段，name 字段是一個爲 String 的非空標量，age 字段爲一個 Int 的可空標量。
2.3 模式 Schema
如果你用過 MongoOSE，那你應該對 Schema 這個概念很熟悉，翻譯過來是『模式』。
它定義了字段的類型、數據的結構，描述了接口數據請求的規則，當我們進行一些錯誤的查詢的時候 GraphQL 引擎會負責告訴我們哪裏查詢有問題，和詳細的錯誤信息，對開發十分友好。
Schema 使用一個簡單的模式語法編寫，稱爲模式描述語言（Schema Definition Language, SDL），我們可以用一個真實的例子來展示一下一個真實的 Schema 文件是怎麼用 SDL 編寫的：
# src/schema.graphql
# Query 入口
type Query {
hello: String
users: [User]!
user(id: String): [User]!
}
# Mutation 入口
type Mutation {
createUser(id: ID!, name: String!, email: String!, age: Int,gender: Gender): User!
updateUser(id: ID!, name: String, email: String, age: Int, gender: Gender): User!
deleteUser(id: ID!): User
}
# Subscription 入口
type Subscription {
subsUser(id: ID!): User
}
type User implements UserInterface {
id: ID!
name: String!
age: Int
gender: Gender
email: String!
}
# 枚舉類型
enum Gender {
MAN
WOMAN
}
# 接口類型
interface UserInterface {
id: ID!
name: String!
age: Int
gender: Gender
}這個例子就是一個簡單的 Schema 文件了，從 Query、Mutation、Subscription 的入口開始定義了各個對象類型或標量類型，這些字段的類型也可能是其他的對象類型或標量類型，這樣組成了一個樹形的結構，而用戶在向服務端發送請求的時候，沿着這個樹選擇一個或多個分支就可以同時獲取多組信息。
注意：在 Query 查詢字段時，是並行執行的，而在 Mutation 變更的時候，是線性執行，一個接着一個，防止同時變更帶來的競態問題，比如說我們在一個請求中發送了兩個 Mutation，那麼前一個將始終在後一個之前執行。
2.4 解析函數 Resolver
前端請求信息到達後端之後，需要由解析函數 Resolver 來提供數據，比如這樣一個 Query：
query {
hello
}那麼同名的解析函數應該是這樣的
Query: {
hello (parent, args, context, info) {
return ...
}
}解析函數接受四個參數，分別爲
-
parent：當前上一個解析函數的返回值 -
args：查詢中傳入的參數 -
context：提供給所有解析器的上下文信息 -
info：一個保存與當前查詢相關的字段特定信息以及 schema 詳細信息的值
解析函數的返回值可以是一個具體的值，也可以是 Promise 或 Promise 的數組。
一些常用的庫可以幫省略一些簡單的解析函數，比如一個字段沒有提供對應的解析函數時，會從上層返回對象中讀取和返回和這個字段同名的屬性。
2.5 請求格式
GraphQL 最常見的是通過 HTTP 來發送請求，那麼如何通過 HTTP 來進行 GraphQL 通信呢
舉個栗子，如何通過 Get/Post 方式來執行下面的 GraphQL 查詢呢
query {
me {
name
}
}Get 是將請求內容放在 URL 中，Post 是在 content-type: application/json 情況下，將 JSON 格式的內容放在請求體裏
# Get 方式
http://myapi/graphql?query={me{name}}
# Post 方式的請求體
{
"query": "...",
"operationName": "...",
"variables": { "myVariable": "someValue", ... }
}返回的格式一般也是 JSON 體
# 正確返回
{
"data": { ... }
}
# 執行時發生錯誤
{
"errors": [ ... ]
}如果執行時發生錯誤，則 errors 數組裏有詳細的錯誤信息，比如錯誤信息、錯誤位置、拋錯現場的調用堆棧等信息，方便進行定位。
3. 實戰
這裏使用 MongoDB + graph-pack 進行一下簡單的實戰，並在實戰中一起學習一下，詳細代碼參見 Github ~
MongoDB 是一個使用的比較多的 NoSQL，可以方便的在社區找到很多現成的解決方案，報錯了也容易找到解決方法。
graph-pack 是集成了 Webpack + Express + Prisma + Babel + Apollo-server + Websocket 的支持熱更新的零配置 GraphQL 服務環境，這裏將其用來演示 GraphQL 的使用。
3.1 環境部署
首先我們把 MongoDB 啓起來，這個過程就不贅述了，網上很多教程；
搭一下 graph-pack 的環境
npm i -S graphpack在 package.json 的 scripts 字段加上：
"scripts": {
"dev": "graphpack",
"build": "graphpack build"
}創建文件結構：
.
├── src
│ ├── db // 數據庫操作相關
│ │ ├── connect.js // 數據庫操作封裝
│ │ ├── index.js // DAO 層
│ │ └── setting.js // 配置
│ ├── resolvers // resolvers
│ │ └── index.js
│ └── schema.graphql // schema
└── package.json這裏的 schema.graphql 是 2.3 節的示例代碼，其他實現參見 Github，主要關注 src/db 、src/resolvers、src/schema.graphql 這三個地方
-
src/db：數據庫操作層，包括 DAO 層和 Service 層（如果對分層不太瞭解可以看一下最後一章） -
src/resolvers：Resolver 解析函數層，給 GraphQL 的 Query、Mutation、Subscription 請求提供 resolver 解析函數 -
src/schema.graphql：Schema 層
然後 npm run dev ，瀏覽器打開 http://localhost:4000/ 就可以使用 GraphQL Playground 開始調試了，左邊是請求信息欄，左下是請求參數欄和請求頭設置欄，右邊是返回參數欄，詳細用法可以參考 Prisma 文檔
3.2 Query
首先我們來試試 hello world，我們在 schema.graphql 中寫上 Query 的一個入口 hello，它接受 String 類型的返回值
# src/schema.graphql
# Query 入口
type Query {
hello: String
}在 src/resolvers/index.js 中補充對應的 Resolver，這個 Resolver 比較簡單，直接返回的 String
// src/resolvers/index.js
export default {
Query: {
hello: () => 'Hello world!'
}
}然後我們在 Playground 中進行 Query
# 請求
query {
hello
}
# 返回值
{
"data": {
"hello": "Hello world!"
}
}這裏拿到了 hello world 返回值，hello world 總是如此愉快，下面我們來進行稍微複雜一點的查詢
一個查詢入口 users 查找所有用戶列表，返回一個不可空但長度可以爲 0 的數組，數組中如果有元素，則必須爲 User類型；另一個查詢入口 user 接受一個字符串，查找 ID 爲這個字符串的用戶，並返回一個 User 類型的可空字段
# src/schema.graphql
# Query 入口
type Query {
user(id: String): User
users: [User]!
}
type User {
id: ID!
name: String!
age: Int
email: String!
}增加對應的 Resolver
// src/resolvers/index.js
import Db from '../db'
export default {
Query: {
user: (parent, { id }) => Db.user({ id }),
users: (parent, args) => Db.users({})
}
}這裏的兩個方法 Db.user、Db.users 分別是查找對應數據的函數，返回的是 Promise，如果這個 Promise 被 resolve，那麼被 resolve 的數據將被作爲結果返回。
然後進行一次查詢就可以查找我們所希望的所有信息
# 請求
query {
user(id: "2") {
id
name
email
age
}
users {
id
name
}
}
# 返回值
{
"data": {
"user": {
"id": "2",
"name": "李四",
"email": "[email protected]",
"age": 18
},
"users": [{
"id": "1",
"name": "張三"
},{
"id": "2",
"name": "李四"
}]
}
}注意這裏，返回的數組只希望拿到 id、name 這兩個字段，因此 GraphQL 並沒有返回多餘的數據，怎麼樣，是不是很貼心呢
3.3 Mutation
知道如何查詢數據，還得了解增加、刪除、修改，畢竟這是 CRUD 工程師必備的幾板斧，不過這裏只介紹比較複雜的修改，另外兩個方法可以看一下 Github 上。
# src/schema.graphql
# Mutation 入口
type Mutation {
updateUser(id: ID!, name: String, email: String, age: Int): User!
}
type User {
id: ID!
name: String!
age: Int
email: String!
}同理，Mutation 也需要 Resolver 來處理請求
// src/resolvers/index.js
import Db from '../db'
export default {
Mutation: {
updateUser: (parent, { id, name, email, age }) => Db.user({ id })
.then(existUser => {
if (!existUser)
throw new Error('沒有這個id的人')
return existUser
})
.then(() => Db.updateUser({ id, name, email, age }))
}
}Mutation 入口 updateUser 拿到參數之後首先進行一次用戶查詢，如果沒找到則拋個錯，這個錯將作爲 error 信息返回給用戶，Db.updateUser 這個函數返回的也是 Promise，不過是將改變之後的信息返回
# 請求
mutation UpdataUser ($id: ID!, $name: String!, $email: String!, $age: Int) {
updateUser(id: $id, name: $name, email: $email, age: $age) {
id
name
age
}
}
# 參數
{"id": "2", "name": "王五", "email": "[email protected]", "age": 19}
# 返回值
{
"data": {
"updateUser": {
"id": "2",
"name": "王五",
"age": 19
}
}
}這樣完成了對數據的更改，拿到了更改後的數據，並且給定希望返回哪些字段。
### 3.4 Subscription
GraphQL 還有一個有意思的地方就是它可以進行數據訂閱，當前端發起訂閱請求之後，如果後端發現數據改變，可以給前端推送實時信息，我們用一下看看
照例，首先在 Schema 中定義 Subscription 的入口
# src/schema.graphql
# Subscription 入口
type Subscription {
subsUser(id: ID!): User
}
type User {
id: ID!
name: String!
age: Int
email: String!
}然後補充上它的 Resolver
// src/resolvers/index.js
import Db from '../db'
const { PubSub, withFilter } = require('apollo-server')
const pubsub = new PubSub()
const USER_UPDATE_CHANNEL = 'USER_UPDATE'
export default {
Mutation: {
updateUser: (parent, { id, name, email, age }) => Db.user({ id })
.then(existUser => {
if (!existUser)
throw new Error('沒有這個id的人')
return existUser
})
.then(() => Db.updateUser({ id, name, email, age }))
.then(user => {
pubsub.publish(USER_UPDATE_CHANNEL, { subsUser: user })
return user
})
},
Subscription: {
subsUser: {
subscribe: withFilter(
(parent, { id }) => pubsub.asyncIterator(USER_UPDATE_CHANNEL),
(payload, variables) => payload.subsUser.id === variables.id
),
resolve: (payload, variables) => {
console.log('🚢 接收到數據： ', payload)
}
}
}
}這裏的 pubsub 是 apollo-server 裏負責訂閱和發佈的類，它負責收到訂閱的時候返回一個異步迭代器，並且在後端覺得需要發佈訂閱的時候向前端發佈 payload，這裏的 withFilter 的作用是過濾掉不需要的訂閱消息，詳細用法參照訂閱過濾器。
首先我們發佈一個訂閱請求
# 請求
subscription subsUser($id: ID!) {
subsUser(id: $id) {
id
name
age
email
}
}
# 參數
{ "id": "2" }然後我們用剛剛的數據更新操作來進行一次數據的更改，那麼我們將獲取並打印出 pubsub.publish 發佈的 payload，這樣就完成了數據訂閱。
在 graph-pack 中數據推送是基於 websocket 來實現的，可以在通信的時候打開 Chrome DevTools 看一下。
4. 總結
目前前後端的結構大概如下圖。後端通過 DAO 層與數據庫連接，服務於主要處理業務邏輯的 Service 層，爲 Controller 層提供數據源併產出 API；前端通過瀏覽器 URL 進行路由命中獲取目標視圖狀態，而頁面視圖是由組件嵌套組成，每個組件維護着各自的組件級狀態，一些稍微複雜的應用還會使用集中式狀態管理的工具，比如 Vuex、Redux、Mobx 等。前後端只通過 API 來交流，這也是現在前後端分離開發的基礎。
如果使用 GraphQL，那麼後端將不再產出 API，而是將 Controller 層維護爲 Resolver，並且和前端維護一套 Schema，這個 Schema 將用來生成接口文檔，前端直接通過 Schema 或生成的接口文檔來進行自己期望的請求。
經過幾年一線開發者的填坑，已經有一些不錯的工具鏈可以使用於開發與生產，很多語言也提供了對 GraphQL 的支持，比如 JavaScript/Nodejs、Java、PHP、Ruby、Python、Go、C# 等。
一些比較有名的公司比如 Twitter、IBM、Coursera、Airbnb、Facebook、Github、攜程等，內部或外部 API 從 RESTful 轉爲了 GraphQL 風格，特別是 Github，它的 v4 版外部 API 只使用 GraphQL。據一位在 Twitter 工作的大佬說硅谷不少一線二線的公司都在想辦法轉到 GraphQL 上，但是同時也說了 GraphQL 還需要時間發展，因爲將它使用到生產環境需要前後端大量的重構，這無疑需要高層的推動和決心。
正如尤雨溪所說，爲什麼 GraphQL 兩三年前沒有廣泛使用起來呢，可能有下面兩個原因：
- GraphQL 的 field resolve 如果按照 naive 的方式來寫，每一個 field 都對數據庫直接跑一個 query，會產生大量冗餘 query，雖然網絡層面的請求數被優化了，但數據庫查詢可能會成爲性能瓶頸，這裏面有很大的優化空間，但並不是那麼容易做。FB 本身沒有這個問題，因爲他們內部數據庫這一層也是抽象掉的，寫 GraphQL 接口的人不需要顧慮 query 優化的問題。
- GraphQL 的利好主要是在於前端的開發效率，但落地卻需要服務端的全力配合。如果是小公司或者整個公司都是全棧，那可能可以做，但在很多前後端分工比較明確的團隊裏，要推動 GraphQL 還是會遇到各種協作上的阻力。
大約可以概括爲性能瓶頸和團隊分工的原因，希望隨着社區的發展，基礎設施的完善，會漸漸有完善的解決方案提出，讓廣大前後端開發者們可以早日用上此利器。
網上的帖子大多深淺不一，甚至有些前後矛盾，在下的文章都是學習過程中的總結，如果發現錯誤，歡迎留言指出~
參考：