stand.fmにGraphQLを導入して、半年。〜導入経緯や技術選択、現状や将来について〜

by Spice-Z

Slide 1

Slide 1 text

　　　　　に GraphQLを導入して、半年。〜導入経緯や技術選択、現状や将来について〜 by spice(@rabspice) on 2022/03/03 @ TECH STAND #7 GraphQL

Slide 2

Slide 2 text

自己紹介 @rabspice ・2021年6月stand.fm入社・React Native / React / express などで　アプリ/ Web / バックエンド　を実装している・マリオカート(switch)をほぼ毎日やってる　(やってる人いたらフレンドになりましょう) 　 spice (Yugo Ogura)

Slide 3

Slide 3 text

stand.fmでは 2021年10月頃から GraphQLを使い始めました。今回は・GraphQLの導入理由・技術選定話・実際に導入しての苦労話についてお話しします！ ※時間がないのであんまり深ぼれなさそう。聞きたことがあったらQ&Aセクションで󰢛

Slide 4

Slide 4 text

目次 1. GraphQL導入の理由 2. ライブラリの技術選定理由 3. 「新機能はGraphQLでやってみよう！」の苦労 4. 現状とこれから 0. stand.fmのアーキテクチャ

Slide 5

Slide 5 text

stand.fmのアーキテクチャ

Slide 6

Slide 6 text

stand.fmのアーキテクチャ App Web React Native React Redux app server web server DB 音声系処理課金系処理その他色々な処理 ※ 全てJSなので、1人がフロント~バックエンド実装を担当することもしばしば

Slide 7

Slide 7 text

目次 1. GraphQL導入の理由 2. ライブラリの技術選定理由 3. 「新機能はGraphQLでやってみよう！」の苦労 4. 現状とこれから 0. stand.fmのアーキテクチャ

Slide 8

Slide 8 text

GraphQL導入の理由

Slide 9

Slide 9 text

・既存のRedux Storeをアプリ上で効率的に使うことが難しかった　・APIコールのキャッシュとして使いたいけど、複雑すぎて開発コスト高い GraphQL導入の理由

Slide 10

Slide 10 text

・コンポーネントの依存するデータが追いにくく、バグが頻発していた　・undefined参照でアプリが落ちるとか・既存のRedux Storeをアプリ上で効率的に使うことが難しかった　・APIコールのキャッシュとして使いたいけど、複雑すぎて開発コスト高い GraphQL導入の理由

Slide 11

Slide 11 text

・コンポーネントの依存するデータが追いにくく、バグが頻発していた　・undefined参照でアプリが落ちるとか・既存のRedux Storeをアプリ上で効率的に使うことが難しかった　・APIコールのキャッシュとして使いたいけど、複雑すぎて開発コスト高い GraphQL導入の理由・クライアントからサーバーサイドにビジネスロジックを寄せたい・本来ならAPIを変更すべきところを、アプリ側の変更で吸収しがち・見通しが悪かったりテストが描きにくかったり

Slide 12

Slide 12 text

Q. GraphQLじゃなくてもよかったのでは？リファクタがんばる SWR や React Query GraphQL （with Relay） APIのキャッシュコンポーネントの依存データ整理ビジネスロジックをサーバーに

Slide 13

Slide 13 text

目次 1. GraphQL導入の理由 2. ライブラリの技術選定理由 3. 「新機能はGraphQLでやってみよう！」の苦労 4. 現状とこれから 0. stand.fmのアーキテクチャ

Slide 14

Slide 14 text

ライブラリの技術選定理由

Slide 15

Slide 15 text

採用したGraphQL関連ライブラリ Apollo Federation Rover CLI DataLoader graphql-codegen Relay

Slide 16

Slide 16 text

Apollo Gateway GraphQL関連部分のアーキテクチャ App Web app server web server Core Server Relay Rover CLI graphql-codegen Dataloader schema/型生成

Slide 17

Slide 17 text

Q. なぜ Relay ? 「コンポーネントが必要なデータの定義を同ファイルに書くことを強制しやすい」のが良い。（Apollo Clientはデフォルトでやりにくい）

Slide 18

Slide 18 text

コンポーネントファイルの中に必要なデータの定義を書く実際にデータを使う時は Relayが用意するhooksでデータを取り出す子

Slide 19

Slide 19 text

子親親でもRelayのhooksを使ってデータを取り出す子にはデータが含まれるオブジェクトを渡す子コンポーネントで必要な Fragment(データの定義) を必ず展開

Slide 20

Slide 20 text

このあたりのRelayのコンセプトは、公式ドキュメントの「Principles And Architecture > Thinking in Relay」に書いてあります。 https://relay.dev/docs/principles-and-architecture/thinking-in-relay/

Slide 21

Slide 21 text

Q. Relayのサーバー仕様を満たすの面倒では言うほどでもなさそうですまた、これによりクライアント側で便利なRelayの関数がたくさん使えるのでメリットがかなり上回ってる感じがあります

Slide 22

Slide 22 text

Q. なぜ Apollo Server ・JSのGraphQLサーバーライブラリは他に目ぼしいものがなさそうだった　・RelayとApollo Serverの組み合わせは特に問題ないです・既存のサーバーの構成に則りたい・今後複数のGraphQLサーバー組み合わせたい Apollo Server Apollo Federation

Slide 23

Slide 23 text

目次 1. GraphQL導入の理由 2. ライブラリの技術選定理由 3. 「新機能はGraphQLでやってみよう！」の苦労 4. 現状とこれから 0. stand.fmのアーキテクチャ

Slide 24

Slide 24 text

新機能はGraphQL でやってみよう！の苦労

Slide 25

Slide 25 text

0から学んで実装はとにかく時間がかかった・最初の数人がとにかく頑張って数個の機能を実装したけど大変　・サーバー側/アプリ側の実装のパラダイムシフト　・何も考えないとRESTの設計に引きづられてGraphQLの理解が進まない

Slide 26

Slide 26 text

0から学んで実装はとにかく時間がかかった・⇨ slackに#z-graphqlを作り、知見の集約・⇨ドキュメント読む会を開催して全体で理解しやすく　・https://graphql.org/learn/ ⇨ GraphQL自体　・https://www.apollographql.com/docs/apollo-server/ ⇨ サーバー実装　・https://relay.dev/ ⇨ フロント実装・⇨ 初めて実装する人は、ペアプロで学習コストを下げたり

Slide 27

Slide 27 text

・組織内に知見が少なくて参考になるコードも少ない　➡ 工数増加で実装に遅れが💦 ・工数増加は一時的で、将来回収できるコストだとエンジニアは認識・代表「長期的にメリットあるなら大丈夫です。やりましょう。」・エンジニア「❤」実装工数の一時的な増加

Slide 28

Slide 28 text

目次 1. GraphQL導入の理由 2. ライブラリの技術選定理由 3. 「新機能はGraphQLでやってみよう！」の苦労 4. 現状とこれから 0. stand.fmのアーキテクチャ

Slide 29

Slide 29 text

現状とこれから

Slide 30

Slide 30 text

現状とこれから・新機能は基本GraphQLで開発・既存機能は適宜GraphQLで置き換えている・Relayを使いながらReduxからうまく脱却する・エラーハンドリングや負荷対策・Relay関連の知見についてはたくさんブログを書きたいと思っています（！）

Slide 31

Slide 31 text

質問があれば Q&Aセクション or Meety で！ Thank you !