マイベスト(mybest)
マイベスト、Vue2からReactへフロントエンドをリプレイス。Vue3へのバージョンアップと修正コストが大差ないと判断し、技術課題3割の時間で約9ヶ月かけて移行
商品比較・ランキングメディア「mybest」を運営するマイベストは、25画面ほどの管理画面と商品ランキング表示画面で使っていたVue2をReactへリプレイスした。Vue2→3のバージョンアップにはかなりの修正コストがかかりそうで、Reactに置き換えるのと大差ないと判断したことに加え、TypeScript・Storybook・Apollo Clientといった周辺ツールがReactを主なターゲットにしていること、React HooksやNext.jsのISRなどエコシステムの進化も後押しになった。バックエンドエンジニア中心の時期に合っていた「Easy」なVueから、フロントエンドエンジニアが保守しやすい「Simple」なReactへ移るという考え方で、src/react/ディレクトリでVueとReactを共存させながら画面単位で移行。技術課題3割の時間を使い、9ヶ月ほどかけて(ほぼ)全てのVueをReactへ置き換えた。
課題
Vue2→3の修正コストが大きく、TypeScriptやStorybook等の周辺ツールとの相性も課題だった
アプローチ
src/react/でVueとReactを共存させ、技術課題3割の時間で画面単位にReactへ置き換え
効果
約9ヶ月で(ほぼ)全てのVueをReact化し、Hooks中心のシンプルな設計に移行
背景
マイベストが運営する「mybest」は、商品を比較・ランキング形式で紹介するメディアで、フロントエンドでは商品ランキング表示画面と、コンテンツを管理する管理画面にVue2を使っていた。管理画面は25画面ほどあり、ほぼ全ての画面で編集機能がある。それ以外の画面はRailsのslimで表示している。Vue2→3のバージョンアップにはかなりの修正コストがかかりそうで、Reactに置き換えるのと大差ないのではないかという見立てがあった。加えて、TypeScript・Storybook・Apollo Clientなど多くのツールがReactを主なターゲットとして作られ、Vue対応はプラグインで後から追加される形が多いこと、React HooksやNext.jsのISRなどReact側のエコシステムが進化を続けていることも移行を後押しした。記事では、バックエンドエンジニアが多かった時期にはEasyなVueが合っていたが、フロントエンドエンジニアが増えた今は保守しやすいSimpleなReactが適していると整理している。
移行のプロセス
移行は通常の開発と並行し、技術課題に割ける時間の中で進められた。
- 体制: フロントエンドエンジニアは正社員3名、業務委託(副業)4名
- 時間配分: エンジニアはビジネス課題7割、技術課題3割の配分で時間を使える
- src/react/ディレクトリを作り、VueとReactを共存させる構成に
- 画面単位で順にReactへ置き換え
- vue-apolloへの依存を外し、GraphQL・Apollo Clientのロジックは維持
- 最初の1画面の実装で設計パターンを固めてから横展開
技術課題3割の時間を使い、9ヶ月ほどかけて(ほぼ)全てのVueをReactへリプレイスした。記事では、移行前提だとゼロベースで設計するよりも考慮が必要なポイントが多いと振り返っている。
移行前後の変化
| 指標 | Before | After | |
|---|---|---|---|
| フロントエンドフレームワーク | Vue 2(vue-apollo) | React(Hooks + Apollo Client) | |
| 管理画面の画面数 | 25画面ほど | 25画面ほど | |
| 移行期間 | — | 9ヶ月ほど(技術課題3割の時間) | |
| フロントエンド体制 | — | 正社員3名・業務委託(副業)4名 |
結果
9ヶ月ほどかけて(ほぼ)全てのVueがReactに置き換わった。React Hooksによって関心ごとを分離したシンプルな設計が取りやすくなり、カスタムフックでコードの書き方を統一しやすくなった。Reactは設計に関する公開情報も豊富で、StorybookやApollo Clientとの連携もしやすくなった。今後は、約半分の画面で使われているRailsのslimについてもNext.jsを導入して全画面React化するプロジェクトが動いている。記事中にパフォーマンスやコストの定量的な改善値は明記されていない。
学び
移行前提のリプレイスは、ゼロベースで設計するよりも考慮が必要なポイントが多い。既存コードとの共存方法や段階的な置き換えの単位まで含めて設計し、スケジュールにも余裕を持たせる必要がある。また、Vueを選んだ当時はバックエンドエンジニア中心のチームにEasyさが合っていたように、技術選定はチーム構成の変化に合わせて見直すものだという視点が示されている。
