資訊專欄INFORMATION COLUMN
摘要：本文首發(fā)于個人博客目錄什么是解決了什么問題一個簡單的入門示例什么是官方文檔定義一種用于的查詢語言，有以下特點請求你所要的數(shù)據(jù)不多不少獲取多個資源只用一個請求描述所有可能的類型系統(tǒng)解決了什么問題來說一個實際的場景前后端聯(lián)調(diào)接口一直以來都是特別
本文首發(fā)于個人博客目錄
什么是GraphQL
解決了什么問題
GraphQL一個簡單的入門示例
什么是GraphQL官方文檔定義：一種用于API的查詢語言， Graph + Query
有以下特點
請求你所要的數(shù)據(jù)不多不少
獲取多個資源只用一個請求
描述所有可能的類型系統(tǒng)
解決了什么問題 1. 來說一個實際的場景：前后端聯(lián)調(diào)接口一直以來都是特別費勁的一個環(huán)節(jié)，使用REST接口，接口返回的數(shù)據(jù)格式，數(shù)據(jù)類型（有哪些字段，字段的類型）都是后端自己預(yù)先定義好的，如果返回的數(shù)據(jù)格式并不是調(diào)用者所期望的，作為前端的我們可以通過以下兩種方式去解決
和后端溝通，該接口（更改數(shù)據(jù)源）
自己做一些適配工作（處理數(shù)據(jù)源）
有這種經(jīng)歷的人都知道，讓后端改接口這是一個很不現(xiàn)實方案，尤其是對于三端（web、andriod、ios）公用同一套后端接口的情況下， 讓后端改接口的結(jié)構(gòu)基本不可能，所以一般都是前端自己做一些接口數(shù)據(jù)的適配工作
其實我們真的很希望， 我們需要什么數(shù)據(jù)，需要什么格式，后端就按照什么格式給我們返回什么樣的數(shù)據(jù)結(jié)構(gòu)，我們要哪些字段，后端就只給我們返回我們需要的這些字段， 其他的都不返回，這樣，前端就和后端解耦了，我們不用再每天和后端因為接口問題去撕逼，GraphQL就是一個這樣的思路來幫助我們解決這個前后端聯(lián)調(diào)接口的問題， 在前端直接寫查詢， 后端只管給前端返回前端查詢的這些數(shù)據(jù)；
2. 還有一種場景:一個頁面里展示的信息， info1, info2, info3，前端需要請求多個接口，info1對應(yīng)的接口A中的a字段，info2對應(yīng)的接口B中的b字段，info3對應(yīng)的接口C中的c字段
// /api/user/A
{
id: 1111,
name: "張三",
a: "當(dāng)前頁面要展示的info1",
b: "b"
// 其他字段
}
// /api/order/B
{
id: 2222,
name: "hahah",
a: "a"
b: "當(dāng)前頁面要展示的info2",
// 其他字段
}
// /api/system/C
{
id: 3333,
name: "hehe",
a: "a"
c: "當(dāng)前頁面要展示的info3",
// 其他字段
}
這個時候，稍微有點脾氣的前端，都會去找后端撕逼，
前端A: “就這三個字段，你還讓我請求三個接口，你不能一個接口都返回給我嗎”，
后端B：“哎， 我也想啊，但是xxxxx， 所以我這邊不好改，”，
...
最后那就這樣吧。
當(dāng)然，我舉得這個例子是一個很簡單的場景，實際開發(fā)過程中要比這個還要復(fù)雜；
如果使用GraphQL的話，前端自己寫查詢，這個頁面需要哪些需哪數(shù)據(jù)，后端就返回給哪些數(shù)據(jù)，
這是考慮到后端所有的接口都在同一個域下面，但是一般比較復(fù)雜的系統(tǒng)，后端都會分為不同的域， 用戶域，商品域，基礎(chǔ)模塊域，交易域等等，這時即使用了GraphQL也可能
后端C：“你看其他都不是我負(fù)責(zé)的域，我要是自己給你封裝一個，我自己底層需要經(jīng)過xxxxx等復(fù)雜的步驟去獲取其他域的，這個很復(fù)雜， 你還是直接去他哪個域去查詢吧”，
有兩種方法，
你就再多寫一個GraphQL
自己寫一個node中間層，中間層來處理這些接口數(shù)據(jù)的聚合，換句話說，中間層來聚合成一個GraphQL查詢來返回給前端， 中間層分別取調(diào)用服務(wù)端的三個接口，然后把三個接口返回的數(shù)據(jù)聚合成前端所需要的
GraphQL一個簡單的入門示例 準(zhǔn)備npm i --save express express-graphql graphql cors服務(wù)端代碼
var express = require("express");
var graphqlHTTP = require("express-graphql");
const { buildSchema } = require("graphql");
const cors = require("cors"); // 用來解決跨域問題
// 創(chuàng)建 schema，需要注意到：
// 1. 感嘆號 ！ 代表 not-null
// 2. rollDice 接受參數(shù)
const schema = buildSchema(`
type Query {
username: String
age: Int!
}
`)
const root = {
username: () => {
return "李華"
},
age: () => {
return Math.ceil(Math.random() * 100)
},
}
const app = express();
app.use(cors());
app.use("/graphql", graphqlHTTP({
schema: schema,
rootValue: root,
graphiql: true
}))
app.listen(3300);
console.log("Running a GraphQL API server at http://localhost:3300/graphql")
客戶端代碼
graphql demo
運行結(jié)果
參考
graphql官方文檔
GraphQL 入門介紹
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://www.ezyhdfw.cn/yun/104614.html
摘要：本文實例代碼什么是是一種面向數(shù)據(jù)的查詢風(fēng)格。概述前端的開發(fā)隨著框架全面普及，組件化開發(fā)也隨之成為大勢所趨，各個組件分別管理著各自的狀態(tài)，組件化給前端仔帶來便利的同時也帶來了一些煩惱。 showImg(https://segmentfault.com/img/remote/1460000018479542?w=4928&h=3280); 本文首先介紹了 GraphQL，再通過 Mongo...
摘要：關(guān)注業(yè)務(wù)，而不是技術(shù)將數(shù)據(jù)需求放在它們所屬的客戶端。技術(shù)棧中的每一部分都起著作用技術(shù)棧中所有部分之間的協(xié)作可以借助緩存來完成?，F(xiàn)在，我們來看看另一個貫穿整個技術(shù)棧的功能的例子。你可以認(rèn)為是首個內(nèi)置細(xì)粒度查看的技術(shù)。 本文整理自2017年 GraphQL 峰會上的演講，詳述緩存、追蹤、模式拼接和 GraphQL 未來發(fā)展等有關(guān)話題。 Facebook 開源 GraphQL 至今已兩年有余...
摘要：允許創(chuàng)建零配置的服務(wù)器。這是一種人類可讀的模式語法，稱為規(guī)范與描述語言。類型是表示外觀的自定義對象。為此，創(chuàng)建一個名為的新查詢。這意味著無論何時在服務(wù)器中發(fā)生事件，并且每當(dāng)調(diào)用該事件時，服務(wù)器都會將相應(yīng)的數(shù)據(jù)發(fā)送到客戶端。 showImg(https://segmentfault.com/img/bVbm0c1?w=2560&h=1024); 想閱讀更多優(yōu)質(zhì)文章請猛戳GitHub博客,...
摘要：如下圖嗯，如圖都已經(jīng)查詢到我們保存的全部數(shù)據(jù)，并且全部返回前端了。如圖沒錯，什么都沒有就是查詢服務(wù)的界面。寫好了之后我們在配置一下路由，進(jìn)入里面，加入下面幾行代碼。 GraphQL一種用為你 API 而生的查詢語言，2018已經(jīng)到來，PWA還沒有大量投入生產(chǎn)應(yīng)用之中就已經(jīng)火起來了，GraphQL的應(yīng)用或許也不會太遠(yuǎn)了。前端的發(fā)展的最大一個特點就是變化快，有時候應(yīng)對各種需求場景的變化，不...
閱讀 3772·2021-10-11 10:59
閱讀 1373·2019-08-30 15:44
閱讀 3536·2019-08-29 16:39
閱讀 2957·2019-08-29 16:29
閱讀 1877·2019-08-29 15:24
閱讀 880·2019-08-29 15:05
閱讀 1318·2019-08-29 12:34
閱讀 2463·2019-08-29 12:19
