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