摘要:初始化項目使用初始化項目安裝項目結構如下接口所有接口對封裝接下來對進行封裝,加上中間件實現類似于攔截器的效果。
Graphql嘗鮮
在只學習graphql client端知識的過程中,我們常常需要一個graphql ide來提示graphql語法,以及實現graphql的server端來進行練手。
graphql社區提供了graphiql讓我們使用
graphiql (npm):一個交互式的運行于瀏覽器中的 GraphQL IDE.
但graphiql提供的live demo基本打不開,難道剛接觸graphql就要自己實現graphql的server端?
好在github用graphql寫了一套api,我們可以去這里,登陸后即可體驗一把graphql。
關于graphql的基礎知識可以去這里看看
graphql在前端實現有以下方案。
Relay (github) (npm):Facebook 的框架,用于構建與 GraphQL 后端交流的 React 應用。
Apollo Client (github):一個強大的 JavaScript GraphQL 客戶端,設計用于與 React、React Native、Angular 2 或者原生 JavaScript 一同工作。
graphql-request:一個簡單的彈性的 JavaScript GraphQL 客戶端,可以運行于所有的 JavaScript 環境(瀏覽器,Node.js 和 React Native)—— 基本上是 fetch 的輕度封裝。
Lokka:一個簡單的 JavaScript GraphQL 客戶端,可以運行于所有的 JavaScript 環境 —— 瀏覽器,Node.js 和 React Native。
nanogql:一個使用模板字符串的小型 GraphQL 客戶端庫。
從npm download數量上看Apollo Client是最多的,并且Apollo也有服務端的解決方案,所以這里選擇Apollo Client作為graphql的client端
apollo client對于web 框架都有具體的實現,但是我更希望能像axios那樣去使用graphql,而不是每套web框架都要去學一下具體實現,那樣會折騰死自己。
// 使用vue-cli初始化項目 vue init webpack-simple my-project npm i安裝graphql
npm i apollo-cache-inmemory apollo-client apollo-link apollo-link-http npm i graphql graphql-tag項目結構如下
. ├── index.html ├── package.json ├── package-lock.json ├── README.md ├── src │ ├── App.vue │ ├── graphql // 接口 │ │ ├── search.graphql │ │ └── index.js // export所有接口 │ ├── main.js │ └── utils │ └── graphql.js // 對Apollo-client封裝 └── webpack.config.jsapollo-client
接下來對apollo-client進行封裝,加上中間件(實現類似于axios攔截器的效果)。
graphql.js
import ApolloClient from "apollo-client" import { InMemoryCache } from "apollo-cache-inmemory" import { HttpLink } from "apollo-link-http" import { onError } from "apollo-link-error" import { ApolloLink, from } from "apollo-link" const token = "598ffa46592d1c7f57ccf8173e47290c6db0d549" const Middleware = new ApolloLink((operation, forward) => { // request時對請求進行處理 console.log("Middleware", operation, forward) }) const Afterware = new ApolloLink((operation, forward) => { return forward(operation).map(response => { // 服務器返回數據 console.log("Afterware--response", response) return response }) }) const errorLink = onError(({ graphQLErrors, networkError }) => { if (graphQLErrors) graphQLErrors.map(({ message, locations, path }) => console.log( `[GraphQL error]: Message: ${message}, Location: ${locations}, Path: ${path}`, ), ); if (networkError) console.log(`[Network error]: ${networkError}`); }); const httpLink = new HttpLink({ uri: "https://api.github.com/graphql", // 配置請求url headers: { // 配置header Authorization: `Bearer ${token}` } }) const cache = new InMemoryCache() // 緩存 export default new ApolloClient({ link: from([Middleware, Afterware, errorLink, httpLink]), cache })
配置webpack支持.graphql文件
// 在rules下添加以下規則 { test: /.(graphql|gql)$/, exclude: /node_modules/, loader: "graphql-tag/loader", }
search.graphql
query searchR ($keyword: String!) { search (query: $keyword , type: REPOSITORY){ userCount } }
在/graphql/index.js export所有接口
import client from "../utils/graphql" // import gql from "graphql-tag" import * as searchGql from "./search.graphql" /** searchGql模塊 **/ export const search = (params) => client.query({query: searchGql.search, variables: params})
到這里我們已經可以直接調用/graphql/下導出的function
使用github接口實現一個簡單的搜索功能
具體實現就不貼出來了,全部代碼已經放到github,歡迎star。
run的時候有記得把token換成自己的,因為我的token有可能已經失效。
graphql實現分頁有以下兩種方式:
基于偏移量,需要提供第幾頁, 每頁的數量
基于游標或者id,提供每頁數量,與 游標/id。
對于游標分頁Relay(Facebook家的Graphql庫) 定了一套規范 Relay-style cursor pagination
基于偏移量的分頁實現簡單,但存在以下問題:
性能問題,雖然可以使用 “延遲關聯” 解決,但會使sql語句變得復雜
# 假設 有一個 product商品表,當商品表數量足夠多時,這個查詢會變得非常緩慢, SELECT id, name FROM product LIMIT 1000, 20; # 如果我們提供一個邊界值,比如id,無論翻頁到多么后面,其性能都會很好 SELECT id, name FROM product WHERE id > 1000 LIMIT 20;
刪除列表數據時,導致獲取下一頁的數據缺失
# 假設 總共有11條數據,一頁顯示10條,總頁數為 2 頁。 # 當調用接口刪除 第 1 頁的 1 條數據,然后進行翻頁時,因為只剩下10條數據,所以下面的sql會查不到數據。 SELECT id, name FROM product LIMIT 10, 10;
基于游標/ID 的分頁,也存在硬傷:
如何實現跳往第 n 頁的功能
難道要獲取 相應的游標再進行翻頁? 所以它更適用于無限加載,或者只有 上一頁/下一頁 的情景上,對于跳往第n頁還是需要用到基于偏移量的分頁。
所以我們需要同時支持這兩種分頁。
Relay 定義了 PageInfo,Edges,Edge Types,Node,Cursor等對象 用于實現靈活的分頁。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/95829.html
摘要:在中應用的思考原文發表在簡介熟悉的同學可直接跳過這一章,從實踐一章看起。這也是官方建議的最佳實踐。也就是說,只有在客戶端提交了包含相應字段的時,才會真正去發送相應的請求。在客戶端與服務端均不考慮緩存的情況,客戶端反而會少一個請求。。。 Apollo GraphQL 在 webapp 中應用的思考 原文發表在: https://github.com/kuitos/kui... 簡介 熟悉...
摘要:樣例前端傳入字段和結構。后臺按照前端的需求返回數據。則將前后臺通信直接分為兩大類和。顧名思義,是默認的操作符,代表查詢,是不會給服務端帶來副作用的請求。文檔文檔部分文檔就是前端向后臺描述所需的字段。降低前后端溝通成本。 簡介 showImg(https://segmentfault.com/img/bVbmKX5?w=150&h=150); GraphQL是基于「類型系統」來執行查詢的...
摘要:通過對比各項目過去個月在上新增數量,來評估其在年度的受關注程度,進而選出年度領域崛起的明星項目。也許正因為上述最后一點,在中國擁有大量的擁躉。不僅被中國最大的電商平臺阿里巴巴使用,也獲得了與這些公司青睞。 共 4741 字,讀完需 8 分鐘,速讀 2 分鐘。我有幸參與了該項目的部分中文版翻譯、校對工作,感謝 Sacha Grief,Micheal Ramberu 的統計整理,以及 Fr...
摘要:前言兩篇文章學完了基礎篇原理篇,接下去便是實踐的過程,這個實踐我們使用了如下技術棧去實現一套任務管理系統,源碼就不公開了等穩定后再發布。后續我所在的公司網關團隊會持續實踐,爭取貢獻出更多的解決方案。前言 兩篇文章學完了GraphQL(基礎篇, 原理篇),接下去便是實踐的過程,這個實踐我們使用了如下技術棧去實現一套任務管理系統,源碼就不公開了, 等穩定后再發布。效果如下: showImg(ht...
摘要:我在工程實踐中直接使用類作為對應實體類的。因此我的結論是,此庫并不適用于我的工程實踐。工程實踐中對其應用方式的考慮在的官方教程中建議針對每請求創建新的實例,查詢請求結束則實例們的生命周期結束。 因為自己寫過基于react的前端應用,因此一看到GraphQL就被深深吸引,真是直擊痛點??!服務端開發一直是基于java, Spring的,因此開始研究如何在現有工程框架下加入graphql的支...
閱讀 2067·2021-10-12 10:12
閱讀 788·2021-09-24 09:47
閱讀 1187·2021-08-19 11:12
閱讀 3462·2019-08-29 13:06
閱讀 681·2019-08-26 11:43
閱讀 2563·2019-08-23 17:20
閱讀 1146·2019-08-23 16:52
閱讀 2594·2019-08-23 14:27