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

こちらの発表で使用した資料です
https://standfm.connpass.com/event/239750/

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

5. stand.fmの
   アーキテクチャ
   

   View Slide

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

   View Slide

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

   View Slide

8. GraphQL導入の理由
   

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

29. 現状とこれから
    

    View Slide

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

    View Slide

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

    View Slide