GraphQL(一):GraphQL介紹
GraphQL是什麼
GraphQL是facebook開源的一套數據交互方案,它並不是某種具體的語言或者框架,它只是提供了一套解決方案,這套解決方案經過GraphQL規範進行定義,不一樣語言能夠有本身的GraphQL實現,目前已經有不少語言完成了GraphQL的實現,能夠在這裏查看。git
怎麼使用GraphQL
GraphQL致力於提供一種直觀的彈性語法系統,用以描述客戶端程序設計時的數據需求以及數據交互行爲。通俗地講就是容許客戶端在請求中精確的定義本身須要什麼,服務端根據客戶端的請求精確的返回相應的內容。好比有以下兩個相互關聯的實體:github
Teacher{ name: String phone: String age: Int } School{ id: String name: String address: String teachers: List<Teacher> }
使用GraphQL查詢指定學校的名稱是這樣的:後端
school(schoolId: "schoolId1"){ name }
返回:數據結構
data{ "name" : "北京大學" }
若是想要查詢學校的名稱以及全部老師的名字和電話:框架
school(schoolId: "schoolId1"){ name teachers{ name phone } }
將獲得:工具
data{ "name" : "北京大學" "teachers" : [ { "name" : "李老師", "phone" : "13312345678" }, { "name" : "張老師", "phone" : "13312345673" }, { "name" : "王老師", "phone" : "13312345672" } ] }
以上只演示了GraphQL提供的查詢(query)功能,GraphQL還支持修改(mutation)和訂閱(subscription)。學習
要使得客戶端可使用GraphQL的方式請求數據,首先須要在服務端提供GraphQL服務,這裏能夠查看現有的實現了GraphQL的平臺,關於如何搭建GraphQL的服務,請查看GraphQL(二):GraphQL服務搭建spa
同時,GraphQL提供了強大的開發者工具GraphiQL,能夠實時查看數據模型和API,爲先後端開發者提供了一個便捷的溝通平臺。設計
爲何要使用GraphQL
經過上面的內容,大體能夠了解GraphQL給先後端數據交互帶來的變化。 使用RESTful風格的API,會從指定接口加載數據。每一個接口都明肯定義了返回的數據結構。這意味着客戶端須要的數據,已經在URL中制定好了。GraphQL中採用的方式大相徑庭,GraphQL的API一般只暴露一個接口,而不是返回固定數據結構的多個接口。 GraphQL返回的數據結構不是一成不變的,而是靈活的,讓客戶端來決定真正須要的是什麼數據。code
這樣的變化可以在必定程度上解決使用RESTful風格接口完成數據交互時會遇到的問題:
- 多端點,每一個API都有本身的路徑須要管理
- API數量龐大,新人自學習困難 GraphQL經過圖的方式來組織模型,結合GraphiQL,新人可以快速上手
- 後端數據模型難以規範 RESTful接口多爲頁面驅動,後端可能會設計不少差異不大的模型,目前並無一種強約束去要求後端開發人員規範模型,GraphQL要求在一開始就完成業務模型的分析和定義,避免後面業務模型的泛濫
- 在API設計時每每是面向頁面的,而頁面相比模型具備更差的穩定性
- API文檔維護工做量大 RESTful的API須要管理大量文檔,可是依然存在文檔更新、文檔查閱方便的問題,雖然能夠動用人力完善工具去解決,可是GraphQL自然就自帶文檔工具特性。咱們在定義字段時,一併寫上description,經過GraphiQL能夠實時查看:
type School { id: ID! # 學校id schoolId: String # 學校名稱 schoolName: String # 學校年齡 schoolAge: Int # 學校地址 schoolAddress: String # 學校包含的老師 teachers: [Teacher] # 校長 master: String }
GraphiQL中查看: 6. 數據聚合較爲麻煩 這是在後端常常須要處理的問題,好比,客戶端須要一些數據,咱們定義了一個RESTful的接口,可是這些數據分別在A和B服務中,最終咱們會在後臺手動聚合A和B的數據到一個模型裏返回。而GraphQL經過不一樣的Resolver自然完成了數據聚合功能
GraphQL解除了接口和數據之間的綁定,對業務數據模型作了抽象和整理,以圖的方式來明確模型之間的關係,經過這些關係,具體業務場景能夠定製本身的數據,不一樣的業務場景只要基於一樣一套基礎數據模型就能夠複用過往的接口。
以上好處講起來有些抽象,須要多多實踐多多體會。