Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
GraphQL and Relay Intro
Search
Jeremy Lu
August 26, 2015
Technology
0
210
GraphQL and Relay Intro
reactjs.tw 八月小聚簡報,介紹 GraphQL, Relay。
Jeremy Lu
August 26, 2015
Tweet
Share
More Decks by Jeremy Lu
See All by Jeremy Lu
採用 TypeScript 前你該考慮的十件事
coodoo
1
2.3k
React Conf 2019 回顧 與 2020 前端開發趨勢展望
coodoo
0
590
前端開發的再次典範轉移 如何走出混亂並讓複雜變得可掌控
coodoo
9
2k
ReactVR - a quick glance
coodoo
2
160
React Native 帶來的跨平台 mobile app 開發典範轉移
coodoo
6
3k
Reactjs.tw meetup 7 - 技術匯報
coodoo
22
1.5k
從「學習一次、隨處應用」 談 React Native 帶來的開發典範轉移
coodoo
5
1.3k
Sneak Preivew of React Native
coodoo
18
2.5k
Immutable model 簡介
coodoo
17
1.6k
Other Decks in Technology
See All in Technology
Oracle Database 23ai 新機能#4 Real Application Clusters
oracle4engineer
PRO
0
130
Create Inquiry via Bedrock / 生成 AI で問い合わせ品質は変わるのか?思いついてぱっと作ったものを供養してみる
kazzpapa3
1
210
ORM と向き合う
hoto17296
8
6k
【shownet.conf_】ローカル5Gを活用したウォーキングツアーの体感向上
shownet
PRO
0
300
小さな勉強会の始め方、広げ方、あるいは友達の作り方 / How to Start, Grow, and Build Connections with Small Study Groups
ar_tama
5
2.1k
Oracle GoldenGate 23ai 導入Tips
oracle4engineer
PRO
1
220
普通の Web エンジニアのための様相論理入門 #yapcjapan / YAPC Hakodate 2024
ytaka23
4
780
Low Latency Join Method for Distributed DBMS
yugabytejapan
0
120
C# 13 / .NET 9 の新機能 (RC 1 時点)
nenonaninu
1
1.2k
AWSへのNIST SP800-171管理策 導入に向けての整備/20240930 Mitsutoshi Matsuo
shift_evolve
0
190
LINEヤフー新卒採用 コーディングテスト解説 アルゴリズム問題編
lycorp_recruit_jp
0
13k
Tracking down sources of kernel errors with retsnoop
ennael
PRO
0
150
Featured
See All Featured
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
158
15k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Debugging Ruby Performance
tmm1
73
12k
Why You Should Never Use an ORM
jnunemaker
PRO
53
9k
Web Components: a chance to create the future
zenorocha
310
42k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
22k
Rails Girls Zürich Keynote
gr2m
93
13k
Why Our Code Smells
bkeepers
PRO
334
57k
Building Better People: How to give real-time feedback that sticks.
wjessup
360
19k
Optimising Largest Contentful Paint
csswizardry
31
2.8k
How GitHub (no longer) Works
holman
311
140k
What's in a price? How to price your products and services
michaelherold
243
11k
Transcript
# Overview - GraphQL - 是 query language - 也是一份規格
- GraphQL engine - spec 的實作 - 已有多種語言版本的實作(FB 官方提供 js 實作) - Relay - 一個 data fetching framework - 專用於 GraphQL 的 react client,用來連接 GraphQL server - 目前僅知有 js 實作 # GraphQL # 定位 - micro services 的 API gateway - 可視為 facade pattern 的一種 [圖](API-gateway-1.png) [圖](API-gateway-2-micro-service.png) # 優點 - 提供明確資料接口、型態 - 提供 cache 機制 - 提供 paging 能力 - 目前已知實作 - https://github.com/cryptix/go-graphql - https://github.com/rmosolgo/graphql-ruby - https://github.com/dittos/graphql-py - https://github.com/andimarek/graphql-java - https://github.com/webonyx/graphql-php - https://github.com/sangria-graphql/sangria - https://github.com/joemcbride/graphql-dotnet # 缺點 - 資料存取邏輯仍需人工撰寫 - 已有自動化方案 - https://github.com/RisingStack/graffiti (ORM) - convert your existing models into a GraphQL schema and exposes it over H - 目前還不支援 mutation - https://github.com/solidsnack/GraphpostgresQL - https://github.com/RisingStack/graffiti-mongoose - https://github.com/mickhansen/graphql-sequelize - https://github.com/brysgo/graphql-bookshelf - server 上組合多方資料源花的時間成本可能更高 - 除非原本就用 Graph DB,例如 Neo4j [圖](API-gateway-1.png) - 使用 connection, edges 等怪異名詞 # 技術細節 - schema.js 是重點 - 宣告資料的 Type 與 relationship - 例如一個 User 有許多 todos,此關聯該如何定義?
- database.js - 串接資料源,例如 REST API 或各種 db # Relay
# 定位 - 介於 client 與 server 間的 connector # 優點 - query 與 mutation 都用相同語言(GraphQL) - 每個元件外包一個 relay container 省去層層傳遞 - data 不用透過 context 或 props 層層傳遞 - app 結構變的扁平化,幾乎只有一階 - 資料與元件緊密相依 - 易於管理 - 不會 over/under fetching - 程式易讀、易開發、不易犯錯 - 只要看 view component 內容,就知道它會用到哪些資料 - 元件從此真正完全封裝,也可隨意移到任何層級內,不用擔心資料接口會丟失(因為以往是由上到下逐層傳遞) - 集中式 store 代為處理資料正規化、cache、存取操作 - made efficient through caching, batching, re-use, and other means to reduce the size of queries - 這些事原本都要工人智慧來做,現在它自動做好了 - 將來會支援 server 之外的資料源,例如 in-memory, file system, device APIs,也能 offline 操作 - 便於分工,一個人負責寫 schema 與所有 muation - 這個人可能就是原本的後端工程師,因為 REST API 也是他寫的 - 其它 component developer 只要會用 graphql 語法就好 # 缺點 - 目前 client 端只有 react 實作 - ios/android 無法使用,只能繼續透過 REST API 操作 - 所有 CUD 都要寫一支 mutation js,內含六大步驟 # 技術細節 - 功能 - 提供統一的 store - 與 GraphQL server 溝通(透過標準 GET/POST 操作) - 負責所有 model 的 normalization, cache, update... [圖](relay-structure.png) - 提供封裝的 container - 它就是 container component - 大量應用 Higher Order Component 技巧 - 負責 data fetching, binding, redrawing [圖](Containers-HOC-Relay.png) - query 的範例 // todo.js fragments: { todo: () => Relay.QL` fragment on Todo { complete,
id, text, } `, viewer: () => Relay.QL` fragment on
User { ${ChangeTodoStatusMutation.getFragment('viewer')}, ${RemoveTodoMutation.getFragment('viewer')}, } `, }, - mutation 的範例 - 新增一筆 todo _handleTextInputSave = (text) => { Relay.Store.update( new AddTodoMutation({text, viewer: this.props.viewer}) ); } - mutation 的六個關鍵步驟 fragments: 宣告 mutation 操作過程中一定要取得的欄位 getOptimisticResponse: 為了實現 optimistic update 而提供的假資料 getFatQuery: mutation 後要從 server 取回的新資料 getMutation: 指定要操作的 mutation 名稱(要事先定義在 schema.js 內) getConfigs: mutation 後從 server 取回新資料該如何更新本地端舊資料,注意這裡有四種 type: FIELDS_CHANGE, NODE_DELETE, RANGE_ADD, RANGE_DELETE getVariables: 取得 mutation 要用的變數,例如新輸入的 text 內容 - routing - 目前看來將與 react-router 配合 # 結論 - 採用 GraphQL/Relay 的考量 → 省掉的部份 - 原本 client 要手工維護的各種 CRUD 與 optimistic update code 皆可省略 → 不能省的部份 - client 還是要寫 RemoveTodoMutation.js 來定義更新 logic - getFatQuery(), getConfigs(), getOptimisticResonpose()等 ← 雖然最後一定是 copy/paste 直接用 ← 並且將來可省掉這步 - server 上要多一份 schema.js ,頗長 - 而且 CRUD 操作要用它定義的 graph connection 語法,要重學 - 目前 GraphQL/Relay 的規格與範例都還在快速演化中,至少等兩個月再進場不遲 - 現階段摸熟 redux 與週邊配套方案效益最高 - 參考 - Falcor - netflix.github.io/falcor/starter/what-is-falcor.html - Netflix 推出,以 JSON graph 為主的解決方案
- Relay 二三事 (David Chang) - https://goo.gl/jzOKfV - Relay-Chat example
(Edward Chen) - https://github.com/transedward/relay-chat