リリースから5年、Webフロントエンドの経年劣化と向き合う

Transcript

1. リリースから5年、Webフロント エンドの経年劣化と向き合う 2022年10月11日 Muddy Web #3

2. 原 一成 AmebaNewsのシステム概要

3. 3 AmebaNewsとは AmebaNewsでは「ちょっと新しい日常を」 をコンセプトに、芸能人・有名人のエンタ メニュースを中心にお届けしています。中 でもAmebaブログ(アメブロ)発の記事や特集 などを豊富にそろえて画像や動画と併せて 提供しています。

4. 4 AmebaNews Webシステム概要 Desktop Mobile 2017年

5. 5 Desktop • MPAとSPAが合わさったいわばIsomorphic Web App • 大部分のアーキテクチャはAmebaブログを流用 ◦ React,

   React Router, Redux →　悪くはないけどクライアント処理がほぼないAmebaNewsの構成として はやや過剰… →　実装時の考慮も多く、移行もしにくい https://developers.cyberagent.co.jp/blog/archives/636/

6. 6 Mobile • MPA + CDN (Fastly) • AMPをフレームワークとして駆使 •

   一応レスポンシブ対応済み →　AMPの利点もなくなってきた →　実装時にDesktopとMobileの構成が違いすぎる https://developers.cyberagent.co.jp/blog/archives/16818/

7. 7 AmebaNews Webシステム概要 Desktop Mobile

8. 8 AmebaNewsシステム変更方針 • DesktopとMobileの(Ameba的に)良いところを保ったまま統合する ◦ React, MPA + CDN •

   刷新(作り直し)は今回は除外する ◦ サービス規模的に少し整えるだけで目的が達成できそう ◦ システム構成が軽くなるので、次の移行の選択肢も増えるはず • 同時に開発環境(テスト含め)の改善も行う ◦ 今後の機能追加や次の(プチ)刷新でも役立つように

9. 9

10. keiya01 React with SSRをMPA化する _keiya01

11. Section1 はじめに

12. 12 変更前の技術構成 • Reactとexpressを使用して、SSRを実現している(Next.jsなどは使用していない) • ルーティングはreact-router • storeの管理はRedux • (5年前でこのスタックはかなり攻めていたのでは、、？)

13. Section2 どのようにMPA化するか

14. 14 MPA化の方法 • ページ遷移をMPA的に遷移できるようにすれば良い • react-routerのLinkをaタグに置き換える • まずはできるだけ少ない変更で様子を見る

15. 15 サービスへの影響を確認する • FastlyでA/B Testing環境を作り、SPAとMPAでサービスへの影響を確認する ◦ FastlyのA/B Testingはチュートリアルがあるのでとても簡単でした ◦ https://developer.fastly.com/solutions/tutorials/ab-testing/

    • PVなどに影響がないことが確認できたら徐々にMPAの影響範囲を広げていく PPS: SPAが1.6でMPAが1.7 LCP: SPAが1.14s, MPAが1.15s

16. Section3 最適化(リファクタリング)

17. 17 何をやるか • MPAになったことで不要なpackagesやシンプルにできる部分があるのでリファ クタリングしていく ◦ 特にreact-routerとRedux外しについて話します • テストを通して品質を担保する •

    監視などを通してエラーが起きた時にすぐに対応できるようにしておく • そもそもエラーの影響を最小限にできるように工夫をする

18. 18 • NewsアプリなのでSPA的な遷移は重要ではない • Clientの依存を減らして初期読み込みを早くしたい ◦ メンテナンスの観点でも依存が多いほどメンテナンスが大変 • とはいえReactの書き味を残したい •

    将来的にHydrationを局所的にしたReactみたいなものが出て来ればそれを 使えるかも なぜMPAか

19. 19 なぜreact-routerを外すか 最終的にもはや自前の方が楽という結論(MPAだし)

20. 20 なぜReduxを外すか • 昨今の流れとして責務を明確にした上でstateを管理する流れがあるし、 そっちの方がわかりやすい • MPAなのでstoreにデータを溜めておくメリットがない • 今回はグローバルで管理するデータが数えるほどしかないのでstoreは React.Contextで管理する

    • MPAなのでreact-queryなども使わずfetchをhooksでラップしたものを使い 特にクライアントでデータのキャッシュはしない

21. 21 進め方 1. テストや監視周りの準備 2. server側のreact-routerをexpressベースに置き換える 3. server側のredux外し 4. client側のredux外し

    5. client側のreact-routerを外す

22. 22 基本方針 • 進めていくにあたって次の方針を意識しました • できるだけインターフェイスを変えない • テンプレートを作ってできるだけロジックを考えずに置き換えができる状態を 作る •

    他の施策もあるので既存のコードと新規のコードを共存させつつ徐々に置き換 えていく • 既存の部分を外しやすいように新規のコードを追加していく

23. 23 テストや監視周りの準備 • initialStateの変更をテストするためにsnapshotテストを行う ◦ 意図せずSSRの内容が変わるのを防ぐ ◦ puppeteerでHTMLに埋め込まれたstateを取得し、JSONとして保存してお き、変更後に比較する ◦

    参考: https://efcl.info/2018/02/02/snapshot-test/ • FastlyのA/B Testingを使い、Reduxありなし、react-routerありなしのケース を作成し、影響がないことを確認しつつ変更を適用していく • DatadogとSentryにA/Bのケースのメトリクスを送り、それぞれで変化がないこ とを確認する

24. 24 そもそもSSRの仕組み 1. それぞれのページでfetchなどを通してデータを取得 2. Appコンポーネントに取得したデータを渡す 3. Server側でReactのAppコンポーネント(一番親のコンポーネント)をHTMLの文字 列に変換する 4.

    この時にAppコンポーネントではpage(path)に応じたコンポーネントをルーティ ングする(react-routerなどの役割) 5. HTMLに変換する際にSSRで使用したデータをwindow.INITIAL_STATEなどに入 れておいてhydorationできるようにしておく 6. ハイドレーションの際にSSR時のコンポーネントとクライアントが一致するよう にクライアントでもルーティングを行う

25. 25 1. 既存のものとは別に新しく `renderHTML` という共通関数を定義し、この関数に initialPropsを渡すとSSRされて、SSRしない場合は何も渡さなければOK 2. できるだけ振る舞いを変えないために、react-routerによって定義されていた propsなどはSSR時に渡すようにする 3.

    ルーティングのディレクトリ構成はNext.jsに寄せて理解しやすい構成に Server側のreact-routerをexpressベースに置き換える

26. 26 Server側のreact-routerをexpressベースに置き換える • pagesRoutesをエントリーポイントで `app.use(pagesRoutes());` のように呼び出 してルーティングする • `isGoodbyeRedux` の場合、以降の

    path に はマッチしないので既存のコードに変更を 加えることなく新しく書き加えることがで きる

27. 27 1. redux-connectというライブラリを通してSSRしていました 2. Serverのroutingに合わせて新規ページを作り、Redux actionと同じfetch処理 を呼び出します 3. fetchしたデータをコンポーネントのpropsに合わせて渡す Server側Redux外し

28. 28 Server側Redux外し • 新規ページのSSR部分 • renderHTMLにinitialPropsを渡す Before After

29. 29 1. useFetchのようなfetch用のHooksを作る 2. ClassコンポーネントをFunctionコンポーネントに書き換える 3. A/BテストのためにReduxのコードを残しつつ新規のコードを書き足す Client側Redux外し

30. 30 Client側Redux外し • ベースとなるuseFetchの内部でA/B Testing 判定をしている • 各API用のHooksは`useFetch`を経由してAPI にアクセスする

31. 31 Client側Redux外し • 改善前はClassコンポーネントで書かれ ていた • Atomic デザイン organisms で

    fetch し ていたためどうしても同一コンポーネン トに修正を加える必要があった • Container層など一枚挟んであればもう 少し置き換えやすかったかも(教訓) Before After

32. 32 Client側react-router外し 1. react-router@v3を最新に上げるの辛い 2. universal-router likeなシンプルな独自routerを作る 3. SSR時とHydration時にルーティングを走らせる 4.

    これを各ページごとに適用していく

33. 33 Client側react-router外し • universal-router likeなrouterの 定義 • マッチしたコンポーネントを返す • Code

    Splittingは未対応

34. 34 Client側react-router外し • Client側でのrouterの出しわけ • initialPropsにreact-routerを使う かどうかを入れている ◦ 使わない場合はlocation系の データをinitialPropsに入れ

    る ◦ initialPropsはSSRで渡ってく るデータ • Serverの場合は`renderToString`に した上で同じようなコードになる

35. 35 最後にA/Bテストのコードを外す 1. 1ヶ月ほど様子を見たのちに、一気に外していきました。 2. バンドルサイズが合計で 59.66KB(gzip) 減りました • react-router:

    33.94KB(gzip) • Redux: 25.73KB(gzip)

36. Section4 まとめ

37. 37 まとめ • react-router v3 のドキュメントがないのは辛かったです • React の SSR

    周りの挙動を再理解する良い機会でした • Router周りも深く知ることができてよかったです

38. 高見 駿介 Developer Experience の改善 shunke07

39. はじめに 話すこと/話さないこと

40. 40 • ユーザー体験：パフォーマンス、アクセシビリティ、UI/UX , etc. • 開発体験：プロダクティビティ、コードの品質 , etc. →　時流によって変化し、何もしなければ劣化していく...

    アプリケーションの品質とフロントエンドの責務

41. 41 • ユーザー体験：パフォーマンス、アクセシビリティ、UI/UX , etc. • 開発体験：プロダクティビティ、コードの品質 , etc. ←こちらのお話

    参考 ：https://developerexperience.io/practices/good-developer-experience #what-is-a-good-developer-experience アプリケーションの品質とフロントエンドの責務

42. 42 開発体験が良くない：AmebaNewsの場合 メンテナンスコストが高い • 実装における心理的安全性が低い（実装のハードルが高い） ◦ 設計および依存関係がレガシー ◦ 静的型付けがない •

    コードレビューの負荷が大きい ◦ テストコードがない ◦ CIでのチェックがなされていない • ビルドとデプロイに時間がかかる

43. 課題その1 実装における心理的安全性が低い （実装のハードルが高い）

44. 44 改善：実装における心理的安全性が低い • 開発ガイドラインの作成 ◦ UIコンポーネント、テスト、パフォーマンスなどに関して • Linterの運用改善 ◦ husky,

    lint-staged, stylelintの導入 • 脱 Git Submodule • TypeScript化

45. 45 • できるだけ厳密に型付けする ◦ compilerOptions の strict オプションを true に

    ◦ @typescript-eslint/eslint-plugin の利用 ◦ ts-migrateは利用しない • fetch周りなど重要なロジックを優先して対応する • 新規の開発では必ずTypeScriptで実装する TypeScript化：実装方針

46. 46 APIリクエスト/レスポンスの型定義は Open APIをもとに生成して、fetch周 りをお型付け（お片付け） https://github.com/drwpow/openapi -typescript TypeScript化：fetch周り

47. 47 TypeScript化：結果 • 15745行を置き換えられた（新規実装分含む） → スクリプト全体の約65% • コンポーネント以外のロジックはすべて置き換え完了

48. 課題その2 コードレビューの負荷が大きい

49. 49 改善：コードレビューの負荷が大きい • 単体テスト・UIテスト ◦ Jest, Mocha, React Testing Library

    • CIでのチェック ◦ Lint ◦ テスト ◦ パフォーマンスバジェット：https://github.com/ai/size-limit • Storybook ◦ PRごとのPreview

50. 50 PR ごとの Storybook Preview PRごとにStorybookの成果物をデプロイするCIワークフローを作成 • 生成したPreview URLをコメントで通知 •

    ローカルでのビルドを必要とせずにStorybookの実装を確認できる形に

51. 課題その3 ビルドとデプロイに時間がかかる

52. 52 改善：ビルドとデプロイに時間がかかる • Webpack のバージョン更新 ◦ v3 → v4 •

    CI の移行 ◦ Jenkins → CircleCI → GitHub Actions ◦ CI上のNodeバージョンを上げる：v8 → v14

53. 53 Webpackのバージョン更新 (v3 to v4) • そもそもv3ではStorybookが動作しない • 段階的にv3からv4への移行を目指す •

    基本は公式のガイドに従う：https://webpack.js.org/migrate/4/

54. 54 Webpackのバージョン更新：結果 modeオプション(dev or prd)の指定による最適化 https://webpack.js.org/configuration/mode/ → productionの場合で、平均ビルド時間が約10秒ほど改善 Before After

55. 55 CIの移行 (Jenkins to GitHub Actions) • Nodeのバージョンを上げた (v8→v14) &

    モジュールをCacheするよう にしたことによりビルドなどの実行速度が改善 ◦ アプリケーションのビルドが約1分半ほど短縮 • コード (yml) ベースで各ワークフローを管理できるように

56. おわりに まとめ

57. 57 まとめ • レガシーなアプリケーションの開発体験を様々なアプローチで改善 することができた ◦ サービスの安定リリース、リードタイムの改善に寄与すること ができた ◦ 様々なエコシステムに対する理解を深めることができた

    • 何もしなければ劣化していく、計画的なメンテナンスが必要 • 刷新はアプリケーションの要件、プロダクトの性質に応じて柔軟に

58. ご静聴ありがとうございました