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
stand.fmにGraphQLを導入して、半年。〜導入経緯や技術選択、現状や将来について〜
Search
Spice-Z
March 03, 2022
Programming
3
2.3k
stand.fmにGraphQLを導入して、半年。〜導入経緯や技術選択、現状や将来について〜
こちらの発表で使用した資料です
https://standfm.connpass.com/event/239750/
Spice-Z
March 03, 2022
Tweet
Share
More Decks by Spice-Z
See All by Spice-Z
Native Module入門記録
spicez
3
910
NuxtでSSR時にGoogleOptimize(ABテストツール)を使いたい
spicez
1
1.1k
"transform" Why do we have to use it in CSS animation
spicez
0
5.2k
Other Decks in Programming
See All in Programming
2分台で1500examples完走!爆速CIを支える環境構築術 - Kaigi on Rails 2025
falcon8823
3
3.4k
私達はmodernize packageに夢を見るか feat. go/analysis, go/ast / Go Conference 2025
kaorumuta
2
500
CSC305 Lecture 04
javiergs
PRO
0
260
エンジニアとして高みを目指す、 利益を生み出す設計の考え方 / design-for-profit
minodriven
23
12k
GraphQL×Railsアプリのデータベース負荷分散 - 月間3,000万人利用サービスを無停止で
koxya
1
1.2k
技術的負債の正体を知って向き合う / Facing Technical Debt
irof
0
110
詳しくない分野でのVibe Codingで困ったことと学び/vibe-coding-in-unfamiliar-area
shibayu36
3
4.6k
LLMとPlaywright/reg-suitを活用した jQueryリファクタリングの実際
kinocoboy2
4
670
ソフトウェア設計の実践的な考え方
masuda220
PRO
3
500
Things You Thought You Didn’t Need To Care About That Have a Big Impact On Your Job
hollycummins
0
180
どの様にAIエージェントと 協業すべきだったのか?
takefumiyoshii
2
620
株式会社 Sun terras カンパニーデック
sunterras
0
250
Featured
See All Featured
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.2k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.6k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.5k
What's in a price? How to price your products and services
michaelherold
246
12k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
Build your cross-platform service in a week with App Engine
jlugia
232
18k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
45
2.5k
Done Done
chrislema
185
16k
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
GraphQLとの向き合い方2022年版
quramy
49
14k
Transcript
に GraphQLを導入して、半年。 〜導入経緯や技術選択、現状や将来について〜 by spice(@rabspice) on 2022/03/03 @ TECH STAND
#7 GraphQL
自己紹介 @rabspice ・2021年6月stand.fm入社 ・React Native / React / express などで
アプリ/ Web / バックエンド を実装している ・マリオカート(switch)をほぼ毎日やってる (やってる人いたらフレンドになりましょう) spice (Yugo Ogura)
stand.fmでは 2021年10月頃から GraphQLを使い始めました。 今回は ・GraphQLの導入理由 ・技術選定話 ・実際に導入しての苦労話 についてお話しします! ※時間がないのであんまり深ぼれなさそう。 聞きたことがあったらQ&Aセクションで
目次 1. GraphQL導入の理由 2. ライブラリの技術選定理由 3. 「新機能はGraphQLでやってみよう!」の苦労 4. 現状とこれから 0.
stand.fmのアーキテクチャ
stand.fmの アーキテクチャ
stand.fmのアーキテクチャ App Web React Native React Redux app server web
server DB 音声系 処理 課金系 処理 その他色々な処理 ※ 全てJSなので、1人がフロント~バックエンド実装を担当することもしばしば
目次 1. GraphQL導入の理由 2. ライブラリの技術選定理由 3. 「新機能はGraphQLでやってみよう!」の苦労 4. 現状とこれから 0.
stand.fmのアーキテクチャ
GraphQL導入の理由
・既存のRedux Storeをアプリ上で効率的に使うことが難しかった ・APIコールのキャッシュとして使いたいけど、複雑すぎて開発コスト高い GraphQL導入の理由
・コンポーネントの依存するデータが追いにくく、バグが頻発していた ・undefined参照でアプリが落ちるとか ・既存のRedux Storeをアプリ上で効率的に使うことが難しかった ・APIコールのキャッシュとして使いたいけど、複雑すぎて開発コスト高い GraphQL導入の理由
・コンポーネントの依存するデータが追いにくく、バグが頻発していた ・undefined参照でアプリが落ちるとか ・既存のRedux Storeをアプリ上で効率的に使うことが難しかった ・APIコールのキャッシュとして使いたいけど、複雑すぎて開発コスト高い GraphQL導入の理由 ・クライアントからサーバーサイドにビジネスロジックを寄せたい ・本来ならAPIを変更すべきところを、アプリ側の変更で吸収しがち ・見通しが悪かったりテストが描きにくかったり
Q. GraphQLじゃなくてもよかったのでは? リファクタ がんばる SWR や React Query GraphQL (with
Relay) APIの キャッシュ コンポーネント の依存データ 整理 ビジネス ロジック をサーバーに
目次 1. GraphQL導入の理由 2. ライブラリの技術選定理由 3. 「新機能はGraphQLでやってみよう!」の苦労 4. 現状とこれから 0.
stand.fmのアーキテクチャ
ライブラリの 技術選定理由
採用したGraphQL関連ライブラリ Apollo Federation Rover CLI DataLoader graphql-codegen Relay
Apollo Gateway GraphQL関連部分のアーキテクチャ App Web app server web server Core
Server Relay Rover CLI graphql-codegen Dataloader schema/型生成
Q. なぜ Relay ? 「コンポーネントが必要なデータの定義を 同ファイルに書くことを強制しやすい」のが良い。 (Apollo Clientはデフォルトでやりにくい)
コンポーネントファイルの中に 必要なデータの定義を書く 実際にデータを使う時は Relayが用意するhooksで データを取り出す 子
子 親 親でもRelayのhooksを使って データを取り出す 子にはデータが含まれるオブ ジェクトを渡す 子コンポーネントで必要な Fragment(データの定義) を必ず展開
このあたりのRelayのコンセプトは、 公式ドキュメントの 「Principles And Architecture > Thinking in Relay」 に書いてあります。
https://relay.dev/docs/principles-and-architecture/thinking-in-relay/
Q. Relayのサーバー仕様を満たすの面倒では 言うほどでもなさそうです また、これによりクライアント側で便利なRelayの関数がたくさん使えるので メリットがかなり上回ってる感じがあります
Q. なぜ Apollo Server ・JSのGraphQLサーバーライブラリは他に目ぼしいものがなさそうだった ・RelayとApollo Serverの組み合わせは特に問題ないです ・既存のサーバーの構成に則りたい ・今後複数のGraphQLサーバー組み合わせたい Apollo
Server Apollo Federation
目次 1. GraphQL導入の理由 2. ライブラリの技術選定理由 3. 「新機能はGraphQLでやってみよう!」の苦労 4. 現状とこれから 0.
stand.fmのアーキテクチャ
新機能はGraphQL でやってみよう! の苦労
0から学んで実装はとにかく時間がかかった ・最初の数人がとにかく頑張って数個の機能を実装したけど大変 ・サーバー側/アプリ側の実装のパラダイムシフト ・何も考えないとRESTの設計に引きづられてGraphQLの理解が進まない
0から学んで実装はとにかく時間がかかった ・⇨ slackに#z-graphqlを作り、知見の集約 ・⇨ドキュメント読む会を開催して全体で理解しやすく ・https://graphql.org/learn/ ⇨ GraphQL自体 ・https://www.apollographql.com/docs/apollo-server/ ⇨ サーバー実装
・https://relay.dev/ ⇨ フロント実装 ・⇨ 初めて実装する人は、ペアプロで学習コストを下げたり
・組織内に知見が少なくて参考になるコードも少ない ➡ 工数増加で実装に遅れが💦 ・工数増加は一時的で、将来回収できるコストだとエンジニアは認識 ・代表「長期的にメリットあるなら大丈夫です。やりましょう。」 ・エンジニア「❤」 実装工数の一時的な増加
目次 1. GraphQL導入の理由 2. ライブラリの技術選定理由 3. 「新機能はGraphQLでやってみよう!」の苦労 4. 現状とこれから 0.
stand.fmのアーキテクチャ
現状とこれから
現状とこれから ・新機能は基本GraphQLで開発 ・既存機能は適宜GraphQLで置き換えている ・Relayを使いながらReduxからうまく脱却する ・エラーハンドリングや負荷対策 ・Relay関連の知見についてはたくさんブログを書きたいと思っています(!)
質問があれば Q&Aセクション or Meety で! Thank you !