マイベストのREST APIをGraphQLに置き換えた話

tsukiji.graphql x ハッカー鮨で発表した資料です

Transcript

1. マイベストのREST APIをGraphQLに置き換えた話 Kyohei Katada (@katakyo_51) update April 19, 2024
2. ⾃⼰紹介 Index 1 GraphQLへの移⾏の背景 2 移⾏⼿順に関して 3 移⾏時の気づき 4 結果 5
3. ⽚⽥ 恭平 Katada Kyohei Backend Engineer 23卒にマイベストのバックエンドエンジニアとして⼊社 触る技術: Ruby on Rails, GraphQL, Next.jsを触ります 趣味: サウナ週⼀くらいで⾏きます、野球観戦、国内観光が最近の趣味 最近、社内の脱⽑の検証で、すね⽑の⼀部が⽣えてこなくなりました 画像 ⾃⼰紹介
4. GraphQLへの移⾏の背景 画像
5. マイベストは2019年からGraphQLを導⼊しているが、導⼊の背景として以下の3つの理由がある GraphQL移⾏の背景 マイベストのGraphQLの導⼊の背景 1 2 3 スキーマと型によってインタフェースが定義される オーバーフェッチやアンダーフェッチを防げる クエリがクライアント（フロントエンド）側で柔軟に調整できる 規約‧書き⽅が統⼀できる 運⽤が（⽐較的）容易である OpenAPIは数が増えれば増えるほど運⽤が⼤変になってくる
6. GraphQL移⾏の背景 mybestのwebアプリケーション mybest favlist admin
7. GraphQL移⾏の背景 2023年4⽉時の状況 • ⾃分が新卒⼊社したタイミングではmybestの表側のみGraphQLのみ終わっており、管理画⾯ (admin)や新規事業のFavlistは移⾏が途中もしくはほぼ⼿がついていない状態であった favlist admin Railsの画⾯とNext.jsの画⾯が混在 mybest Next.jsに移⾏が完了
8. GraphQL移⾏の背景 2023年4⽉時の状況 ‧FrontendもReact/Slimが混在しており、Next.jsに置き換えるにあたり、マイベストのサービスの REST API通信を新卒2⼈が中⼼となってGraphQLに置き換えるプロジェクトが始まった Backend Frontend API
9. 移⾏の⼿順 画像
10. 移⾏の⼿順 移⾏の⼤まかな⼿順 ❶既存のAPIの調 査 ❷GraphQL スキーマ定義 ❸GraphQL Resolverの実装 ❹Next.js/ GraphQLの繋ぎ込 み 以下のような⼯程でREST APIからGraphQLへ置き換えた 1. 既存のAPIの調査 2. GraphQLスキーマ定義 3. GraphQL Resolverの実装 4. Next.js/ GraphQLの繋ぎ込み 5. 不要になったソースコードの削除 ❺不要になった ソースコードの削 除
11. 移⾏の⼿順① 既存のAPIの調査 • RailsのControllerやroutingなどを調べ、置き換え対象のAPIを洗い出す • QueryかMutationかはREST APIのHTTPメソッドによって判断する 操作 REST SQL GraphQL データ取得 GET Select Query データ追加 POST Create Mutation データ更新 PATCH Update Mutation データ削除 DELETE Delete Mutation イベント監視 - - Subscription
12. 既存のAPIの調査 • Controllerや画⾯をみて、例えばIndexメ ソッドやEditメソッドのような表⽰系なら QueryとしてAPIを作成する • Createメソッド、Updateメソッドのような データ操作をするようなメソッドなら MutationとしてAPIを作成する これを地道に調査します Query Mutation Query Mutation 移⾏の⼿順①
13. 移⾏の⼿順① 既存のAPIの調査 • プロジェクトの開始時はGraphQLとREST APIが混在しているような状況であったため、 Notionに置き換える対象の画⾯やAPIを洗い出して進捗を可視化できるようにした
14. • 今回は具体例としてUser情報のupdateのMutation を作る 移⾏の⼿順② GraphQLの実装 • Userテーブルには以下のカラムがあるとする • リダイレクトの処理はFrontendで⾏うためAPIの 処理としては書かない カラム名 型 nullable ID ID false name String false email String false
15. • Resolverで返す値の型やnullableかはObjectTypeとして定義する 移⾏の⼿順② GraphQLスキーマ定義(ObjectTypeの実装)
16. ‧Mutationの処理に必要な引数をInputTypeとして定義する 移⾏の⼿順② GraphQLスキーマ定義(InputTypeの実装)
17. 先程定義したObjectTypeやInputTypeをfieldやargumentの型として定義しResolver関数を書く 移⾏の⼿順③ GraphQL Resolverの実装(Mutationの実装) • ユーザーの名前とメールアドレスを更新す る処理をMutationで実装するなら右のよう なコードになる
18. ‧リプレイスの前後では古いシステムと新しいシステムが混在する ‧mybestではRailsとNext.jsでportを出し分けしてアクセスの向きをNginXの設定で振り分けている 移⾏の⼿順④ リプレイス前後の表⽰の制御に関して
19. • Frontendは既存の画⾯をそのままNext.jsで表⽰できるようにした上でGraphQLの通信でデータ の操作ができるように実装した • Frontend、Backendを置き換えたら、Nginxの設定を変更し、Next.jsの表⽰に切り替える 移⾏の⼿順④ Next.jsの実装とGraphQLの繋ぎ込み
20. • 動作が問題ない、安定稼働できることが確認できたら、使わなくなった古いViewファイルや Controller、Routingなどのファイルを削除する 移⾏の⼿順⑤ 使わなくなったコードの削除
21. 移⾏時の気づき 画像
22. • リプレイスの⼯数の重さによって開発フローを適宜切り替える • スキーマ定義はBackend、Frontend間で合意をとりながら設計をする 移⾏時の気づき ⼤規模な移⾏プロジェクトをやって得た学び
23. 移⾏時にBackend側とFrontend側は実装するAPIの開発の重さによって実装⼿順を変えた 1. 開発⼯数が重めの場合、GraphQLのスキーマ定義のあとResolverはモックデータを返すよう に実装し、FrontendとBackendのロジックを同時に実装する 2. 開発⼯数が軽めの場合は、Backendを作ってからFrontendに実装を依頼する 移⾏時の気づき リプレイスの⼯数の重さによって開発フローを適宜切り替える ❶既存のAPIの調 査 ❷GraphQL スキーマ定義 ❸GraphQL Resolverの実装 ❹Next.js/ GraphQLの繋ぎ込 み ❺不要になった ソースコードの削 除 Backend Frontend 調査 削除
24. リプレイスにあたり、Frontend側でコンポーネントを分けたい画⾯があり、コンポーネント再設計 に伴いスキーマ構造も変更が必要になった Backend側でパフォーマンスや可読性の問題が発⽣したため、再度スキーマ設計が必要になった 移⾏時の気づき スキーマ定義はBackend、Frontend間で合意をとりながら設計をする
25. 複雑なリファクタリングが必要な場合は、DesignDocs にProsConsなどを書いてスキーマの再設計を⾏い、リ プレイスの作業の際にリファクタリングも兼ねて実装し た この際にBackend側とFrontend側でベストなスキーマ が必ずしも⼀致するとは限らないので合意をとりながら 進めると良さそうだった 移⾏時の気づき スキーマ定義はBackend、Frontend間で合意をとりながら設計をする
26. 結果 画像
27. 外部APIを除くほぼ全てのAPIを GraphQLに置き換えることができた
28. ご清聴ありがとうございました
29. 画像 宣伝 4/15(⽉)から1ヶ⽉間テックブログの連載しています！ Xで告知してますので是⾮@mybest_devをフォローしてください！