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
2.1k
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
【若手エンジニア応援LT会】AWS Security Hubの活用に苦労した話
kazushi_ohata
0
170
GitHub Universe: Evaluating RAG apps in GitHub Actions
pamelafox
0
180
ガバメントクラウド先行事業中間報告を読み解く
sugiim
1
1.4k
なんで、私がAWS Heroに!? 〜社外の広い世界に一歩踏み出そう〜
minorun365
PRO
6
1.1k
新R25、乃木坂46 Mobileなどのファンビジネスを支えるマルチテナンシーなプラットフォームの全体像 / cam-multi-cloud
cyberagentdevelopers
PRO
1
130
生成AIとAWS CDKで実現! 自社ブログレビューの効率化
ymae
2
330
2024-10-30-reInventStandby_StudyGroup_Intro
shinichirokawano
1
630
Amazon FSx for NetApp ONTAPを利用するにあたっての要件整理と設計のポイント
non97
1
160
日経電子版におけるリアルタイムレコメンドシステム開発の事例紹介/nikkei-realtime-recommender-system
yng87
1
510
[JAWS-UG金沢支部×コンテナ支部合同企画]コンテナとは何か
furuton
3
260
独自ツール開発でスタジオ撮影をDX!「VLS(Virtual LED Studio)」 / dx-studio-vls
cyberagentdevelopers
PRO
1
180
カメラを用いた店内計測におけるオプトインの仕組みの実現 / ai-optin-camera
cyberagentdevelopers
PRO
1
120
Featured
See All Featured
GraphQLの誤解/rethinking-graphql
sonatard
66
9.9k
For a Future-Friendly Web
brad_frost
175
9.4k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
231
17k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
41
2.1k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
3
370
A designer walks into a library…
pauljervisheath
202
24k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.2k
Docker and Python
trallard
40
3.1k
Typedesign – Prime Four
hannesfritz
39
2.4k
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