食べログのフロントエンドリプレース戦略

フロントエンドリプレース戦略
2021. 03. 10 Tsuji Yuko

Copyright (c) Kakaku.com, Inc. All Rights Reserved.
自己紹介
• 辻祐子 (@osunu)
• 2018年株式会社カカクコム入社
• 食べログフロントエンドチームリーダー
• リプレースプロジェクト推進、採用、チームビルディング
• テニミュ、特撮、アニメが好き

目次 1. 食べログフロントエンドの
リプレースプロジェクトについて
2. リリース戦略について
3. リリース戦略の実現手段について
4. まとめ＆今後の課題

１. 食べログフロントエンドの
リプレースプロジェクトについて

食べログフロントエンドリプレースプロジェクト
 2005年サービス開始で、歴史あるサービス食べログ
 いろいろあってフロントエンドがそこそこカオス!
 メンテナンス性が高いシステムに構築しなおしたい…
 jQueryからReact/TypeScript にリプレースしよう！
 詳しくはブログを読んでね 😚
 食べログフロントエンドエンジニアブログ
 https://note.com/tabelog_frontend

食べログフロントエンドリプレースプロジェクト
React !!
jQuery
jQuery
jQuery

どうして一部だけ？

っていうか
どうやって共存？

２. リリース戦略について
Ruby on Rails上で部分的にリプレースを進めている理由

食べログって、いろんなページがあります！

食べログの状況とプロジェクトの規模感
Ruby on Rails アプリケーション 25個
エントリーポイント 1532ファイル
JSファイル行数 210,760行 ※node_moduleは含まず
1週間にリリースされるissue 100件〜
 短期/中期での全体的なリプレースはスコープ外
 長期戦！！

なぜページ毎のリリースを選択しなかったか
 リリースの単位が大きくなりすぎるから
• 食べログは多機能＆複雑で、ページごとのリリースは数ヶ月〜半年レベル
• 開発期間が長引くほど、機能開発の追従のコストが嵩む
• リリースが単位が大きいほどリスクが大きくなる
 大量のコンポーネント２重管理がメンテナンス性を下げるから
• Reactへの移行期間が長く、その間のメンテナンス性低下を許容できない

部分毎リリースのメリットとデメリット
 メリット😚
• リリースのスパンが短く、機能開発の追従のコストが最小限
• コンポーネント２重管理を抑制できる
• 共存状態が長期間に渡っても、メンテナンス性を下げにくい
 デメリット🥺
• 参考情報・事例が少ない
→しょうがない！そもそもこの規模の事例が殆どない
→重要度の低い小さい機能から段階的に検証＆リリースをする
• ページ内読み込みファイル数が増え、パフォーマンスが低下
→既存のjQuery領域のパフォーマンスを改善する

ページごとの分離を諦めたわけじゃない
Ruby on Rails Ruby on Rails Next.js?
部分的にReactを導入するページ内のReact領域を増やすページ内が全てReactになった時点で
Ruby on Railsから切り離す
→ →

３.リリース戦略の実現手段について
どうやってRuby on Rails上で共存させるか

分離するまで、どうやって共存するのか
Ruby on Rails Ruby on Rails Next.js?
部分的にReactを導入するページ内のReact領域を増やすページ内が全てReactになった時点で
→ →

共存手段選定の観点
共存期間が長くなっても大丈夫なように！
jQueryとReactが
疎結合であること
 jQueryのカオスを引き継ぎたくない
 Reactのリプレースリリース時にjQueryのテストをしたくない
運用が容易であること  共存ページでjQueryの機能開発を今まで通りすすめられるように

共存手段選定の観点
手段1 Reactのコンポーネントを別パッケージとし、
jQueryベースの既存エントリポイントからimportする
手段2 Reactベースの新規エントリポイントから
ReactのコンポーネントとjQueryのコンポーネント両方をimportする
手段3 jQueryベース,Reactベースのエントリポイントを共存させる
採用！

手段１：Reactのコンポーネント別パッケージとし、
※イメージです
Ruby on Rails
(slim or erb)
<html>
<head>
<script src=“jquery.js“></script>
<script src=“jquery-bundled.js“></script>
</head>
<body>
<p>食べログだよ！</p>
<a class=“js-click-shop”>店舗ページへ</a>
<div class=“react-hoge-a”>
<!— ここにreactがレンダリングされる —>
</div>
</body>
</html>
jQuery-component-a
jQuery-entrypoint
jQuery-component-b
React-entrypoint
React-component-b
React-component-a
jQuery関連ファイルだけBundle
React関連ファイルだけBundle
React-bundled.js
❌ 不採用

手段１：Reactのコンポーネント別パッケージとし、
• メリット
• jQueryとReactのコンポーネントが疎結合になる
• ビルドは２回必要だが、それぞれやることはシンプル
• デメリット😨
• Reactの機能をjQueryに組み込んだ状態でおかしな表示や挙動を見つけた時に、ビルド
後のJSの場合、デバッグがしづらく原因の特定が困難。
🙅不採用

手段２：Reactベースの新規エントリポイントから
Ruby on Rails
(slim or erb)
<html>
<head>
<script src=“react-bundled.js“></script>
</head>
<body>
</div>
</body>
</html>
jQuery-component-a
jQuery-component-b
React-entrypoint
React-component-b
React-component-a
jQuery, React関連ファイル全てを１度にBundle
❌ 不採用

手段２：Reactベースの新規エントリポイントから
• メリット
• React公式ドキュメントの「DOM 操作プラグインとのインテグレーション」で紹介され
ており、お手本実装がある
• デメリット😨
• jQueryとReactが疎結合にならない
• ReactベースとjQueryベース両方のページで使われている既存モジュールは、
React/jQuery両方エントリポイントで動くことのテストが必要になる
🙅不採用
🙅不採用

手段３：jQueryベース, Reactベースのエントリポイントを共存させる
Ruby on Rails
(slim or erb)
<html>
<head>
<script src=“jquery.js“></script>
<script src=“jquery-bundled.js“></script>
<script src=“react-bundled.js“></script>
</head>
<body>
</div>
</body>
</html>
jQuery-component-a
jQuery-entrypoint
jQuery-component-b
React-entrypoint
React-component-b
React-component-a
jQuery関連ファイルだけBundle
React関連ファイルだけBundle
⭕ 採用

手段３：jQueryベース, Reactベースのエントリポイントを共存させる
• メリット
• jQueryとReactのコンポーネントが疎結合になる
• ビルドは２回必要だが、それぞれやることはシンプル
• デメリット
• ページ内にランタイムが複数存在する
→jQuery/React双方が影響しあわないよう運用でカバー
• １ページの読込ファイル数が増え、パフォーマンスに影響する
→既にリリースされた機能は規模も小さく許容範囲だった
→jQuery側のパフォーマンス改善をリプレースと並行して行う
🙆採用

実際に手段３でやってみた感想
 jQueryとReactを疎結合にできて良かった✨
• 完全に別でビルドができて、
jQuery,Reactそれぞれのテストだけでリリースが出来るので、機能改善のペースをキープ
 jQueryベースのカオスを引き継がず、Reactはキレイな世界✨
• テストカバレッジ: Branch 95%
• インテグレーションテスト環境の整備（APIのモック化）
• Schemaドリブン、コンポーネントドリブンな開発
• アクセシビリティを意識した実装 👈詳しくはブログで！
 １ページにランタイムが２つあっても運用可能✨
• お互いのDOMを触らない運用ルールで無事故
 パフォーマンスの懸念🥺
• React導入した場合のバンドルサイズを確認できた
• 今後SPのリプレースを進めるときより厳しくパフォーマンスの調整が必要

４. まとめ＆今後の課題

まとめ
 食べログのフロントエンドリプレースプロジェクトは長期戦
 ページごとのリリースは最新機能の追従や２重管理の発生によるコストが大きく
なるため、コンポーネントごとにリリースします
 ページ内でjQueryベース,Reactベースのエントリポイントを共存させ、
コンポーネント毎のリリースを実現しています

今後の課題
 Next.jsの導入！
• １ページまるごとReactにできる未来が見えてきた
• Server Side RenderingでSEO対策をしたい
• Client Side Renderingだけじゃまだ駄目だって
• 絶賛進行中！！
• もう少し進んだらブログに書けたらいいな
• 食べログフロントエンドエンジニアブログ
• https://note.com/tabelog_frontend
Next.js!!!
ページ内が全てReactになった時点で

さいごに
 We are hiring!!!!
 一緒に大規模システムのリプレースに取り組みませんか？
 フロントエンド以外の職種も募集中です❤
 https://www.wantedly.com/projects/254221

食べログのフロントエンドリプレース戦略

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie 食べログのフロントエンドリプレース戦略

Ähnlich wie 食べログのフロントエンドリプレース戦略 (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (9)

食べログのフロントエンドリプレース戦略