マイベストのREST APIをGraphQLに置き換えた話 Kyohei Katada (@katakyo_51) update April 19, 2024

⾃⼰紹介 Index 1 GraphQLへの移⾏の背景 2 移⾏⼿順に関して 3 移⾏時の気づき 4 結果 5

⽚⽥ 恭平 Katada Kyohei Backend Engineer 23卒にマイベストのバックエンドエンジニアとして⼊社 触る技術: Ruby on Rails, GraphQL, Next.jsを触ります 趣味: サウナ週⼀くらいで⾏きます、野球観戦、国内観光が最近の趣味 最近、社内の脱⽑の検証で、すね⽑の⼀部が⽣えてこなくなりました 画像 ⾃⼰紹介

GraphQLへの移⾏の背景 画像

マイベストは2019年からGraphQLを導⼊しているが、導⼊の背景として以下の3つの理由がある GraphQL移⾏の背景 マイベストのGraphQLの導⼊の背景 1 2 3 スキーマと型によってインタフェースが定義される オーバーフェッチやアンダーフェッチを防げる クエリがクライアント（フロントエンド）側で柔軟に調整できる 規約‧書き⽅が統⼀できる 運⽤が（⽐較的）容易である OpenAPIは数が増えれば増えるほど運⽤が⼤変になってくる

GraphQL移⾏の背景 mybestのwebアプリケーション mybest favlist admin

GraphQL移⾏の背景 2023年4⽉時の状況 ● ⾃分が新卒⼊社したタイミングではmybestの表側のみGraphQLのみ終わっており、管理画⾯ (admin)や新規事業のFavlistは移⾏が途中もしくはほぼ⼿がついていない状態であった favlist admin Railsの画⾯とNext.jsの画⾯が混在 mybest Next.jsに移⾏が完了

GraphQL移⾏の背景 2023年4⽉時の状況 ‧FrontendもReact/Slimが混在しており、Next.jsに置き換えるにあたり、マイベストのサービスの REST API通信を新卒2⼈が中⼼となってGraphQLに置き換えるプロジェクトが始まった Backend Frontend API

移⾏の⼿順 画像

移⾏の⼿順 移⾏の⼤まかな⼿順 ❶既存のAPIの調 査 ❷GraphQL スキーマ定義 ❸GraphQL Resolverの実装 ❹Next.js/ GraphQLの繋ぎ込 み 以下のような⼯程でREST APIからGraphQLへ置き換えた 1. 既存のAPIの調査 2. GraphQLスキーマ定義 3. GraphQL Resolverの実装 4. Next.js/ GraphQLの繋ぎ込み 5. 不要になったソースコードの削除 ❺不要になった ソースコードの削 除

移⾏の⼿順① 既存の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

既存のAPIの調査 ● Controllerや画⾯をみて、例えばIndexメ ソッドやEditメソッドのような表⽰系なら QueryとしてAPIを作成する ● Createメソッド、Updateメソッドのような データ操作をするようなメソッドなら MutationとしてAPIを作成する これを地道に調査します Query Mutation Query Mutation 移⾏の⼿順①

移⾏の⼿順① 既存のAPIの調査 ● プロジェクトの開始時はGraphQLとREST APIが混在しているような状況であったため、 Notionに置き換える対象の画⾯やAPIを洗い出して進捗を可視化できるようにした

● 今回は具体例としてUser情報のupdateのMutation を作る 移⾏の⼿順② GraphQLの実装 ● Userテーブルには以下のカラムがあるとする ● リダイレクトの処理はFrontendで⾏うためAPIの 処理としては書かない カラム名 型 nullable ID ID false name String false email String false

● Resolverで返す値の型やnullableかはObjectTypeとして定義する 移⾏の⼿順② GraphQLスキーマ定義(ObjectTypeの実装)

‧Mutationの処理に必要な引数をInputTypeとして定義する 移⾏の⼿順② GraphQLスキーマ定義(InputTypeの実装)

先程定義したObjectTypeやInputTypeをfieldやargumentの型として定義しResolver関数を書く 移⾏の⼿順③ GraphQL Resolverの実装(Mutationの実装) ● ユーザーの名前とメールアドレスを更新す る処理をMutationで実装するなら右のよう なコードになる

‧リプレイスの前後では古いシステムと新しいシステムが混在する ‧mybestではRailsとNext.jsでportを出し分けしてアクセスの向きをNginXの設定で振り分けている 移⾏の⼿順④ リプレイス前後の表⽰の制御に関して

● Frontendは既存の画⾯をそのままNext.jsで表⽰できるようにした上でGraphQLの通信でデータ の操作ができるように実装した ● Frontend、Backendを置き換えたら、Nginxの設定を変更し、Next.jsの表⽰に切り替える 移⾏の⼿順④ Next.jsの実装とGraphQLの繋ぎ込み

● 動作が問題ない、安定稼働できることが確認できたら、使わなくなった古いViewファイルや Controller、Routingなどのファイルを削除する 移⾏の⼿順⑤ 使わなくなったコードの削除

移⾏時の気づき 画像

● リプレイスの⼯数の重さによって開発フローを適宜切り替える ● スキーマ定義はBackend、Frontend間で合意をとりながら設計をする 移⾏時の気づき ⼤規模な移⾏プロジェクトをやって得た学び

移⾏時にBackend側とFrontend側は実装するAPIの開発の重さによって実装⼿順を変えた 1. 開発⼯数が重めの場合、GraphQLのスキーマ定義のあとResolverはモックデータを返すよう に実装し、FrontendとBackendのロジックを同時に実装する 2. 開発⼯数が軽めの場合は、Backendを作ってからFrontendに実装を依頼する 移⾏時の気づき リプレイスの⼯数の重さによって開発フローを適宜切り替える ❶既存のAPIの調 査 ❷GraphQL スキーマ定義 ❸GraphQL Resolverの実装 ❹Next.js/ GraphQLの繋ぎ込 み ❺不要になった ソースコードの削 除 Backend Frontend 調査 削除

リプレイスにあたり、Frontend側でコンポーネントを分けたい画⾯があり、コンポーネント再設計 に伴いスキーマ構造も変更が必要になった Backend側でパフォーマンスや可読性の問題が発⽣したため、再度スキーマ設計が必要になった 移⾏時の気づき スキーマ定義はBackend、Frontend間で合意をとりながら設計をする

複雑なリファクタリングが必要な場合は、DesignDocs にProsConsなどを書いてスキーマの再設計を⾏い、リ プレイスの作業の際にリファクタリングも兼ねて実装し た この際にBackend側とFrontend側でベストなスキーマ が必ずしも⼀致するとは限らないので合意をとりながら 進めると良さそうだった 移⾏時の気づき スキーマ定義はBackend、Frontend間で合意をとりながら設計をする

結果 画像

外部APIを除くほぼ全てのAPIを GraphQLに置き換えることができた

ご清聴ありがとうございました

画像 宣伝 4/15(⽉)から1ヶ⽉間テックブログの連載しています！ Xで告知してますので是⾮@mybest_devをフォローしてください！