Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

@herablog さん、@shunke07 さんと共に Muddy Web #3 で発表した資料です。
https://cyberagent.connpass.com/event/261115/

news.ameba.jpは5年前にデスクトップ版ではReact化、モバイル版ではAMP化が行われました。当時は最先端の技術でしたが時が経つにつれて技術的なトレンドも変化しています。TypeScriptやTanStack、Core Web Vitalsの登場によりWebフロントエンドの技術構成は日々進化しています。 時代の流れに合わせてAmebaNewsでは、脱AMP、脱SPAやTypeScript化などを行いましたので紹介いたします。

Keiya Sasaki

October 11, 2022
Tweet

More Decks by Keiya Sasaki

Other Decks in Programming

Transcript

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

    React Router, Redux → 悪くはないけどクライアント処理がほぼないAmebaNewsの構成として はやや過剰… → 実装時の考慮も多く、移行もしにくい https://developers.cyberagent.co.jp/blog/archives/636/
  2. 6 Mobile • MPA + CDN (Fastly) • AMPをフレームワークとして駆使 •

    一応レスポンシブ対応済み → AMPの利点もなくなってきた → 実装時にDesktopとMobileの構成が違いすぎる https://developers.cyberagent.co.jp/blog/archives/16818/
  3. 8 AmebaNewsシステム変更方針 • DesktopとMobileの(Ameba的に)良いところを保ったまま統合する ◦ React, MPA + CDN •

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

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

    監視などを通してエラーが起きた時にすぐに対応できるようにしておく • そもそもエラーの影響を最小限にできるように工夫をする
  6. 22 基本方針 • 進めていくにあたって次の方針を意識しました • できるだけインターフェイスを変えない • テンプレートを作ってできるだけロジックを考えずに置き換えができる状態を 作る •

    他の施策もあるので既存のコードと新規のコードを共存させつつ徐々に置き換 えていく • 既存の部分を外しやすいように新規のコードを追加していく
  7. 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のケースのメトリクスを送り、それぞれで変化がないこ とを確認する
  8. 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時のコンポーネントとクライアントが一致するよう にクライアントでもルーティングを行う
  9. 31 Client側Redux外し • 改善前はClassコンポーネントで書かれ ていた • Atomic デザイン organisms で

    fetch し ていたためどうしても同一コンポーネン トに修正を加える必要があった • Container層など一枚挟んであればもう 少し置き換えやすかったかも(教訓) Before After
  10. 34 Client側react-router外し • Client側でのrouterの出しわけ • initialPropsにreact-routerを使う かどうかを入れている ◦ 使わない場合はlocation系の データをinitialPropsに入れ

    る ◦ initialPropsはSSRで渡ってく るデータ • Serverの場合は`renderToString`に した上で同じようなコードになる
  11. 37 まとめ • react-router v3 のドキュメントがないのは辛かったです • React の SSR

    周りの挙動を再理解する良い機会でした • Router周りも深く知ることができてよかったです
  12. 41 • ユーザー体験:パフォーマンス、アクセシビリティ、UI/UX , etc. • 開発体験:プロダクティビティ、コードの品質 , etc. ←こちらのお話

    参考 :https://developerexperience.io/practices/good-developer-experience #what-is-a-good-developer-experience アプリケーションの品質とフロントエンドの責務
  13. 42 開発体験が良くない:AmebaNewsの場合 メンテナンスコストが高い • 実装における心理的安全性が低い(実装のハードルが高い) ◦ 設計および依存関係がレガシー ◦ 静的型付けがない •

    コードレビューの負荷が大きい ◦ テストコードがない ◦ CIでのチェックがなされていない • ビルドとデプロイに時間がかかる
  14. 45 • できるだけ厳密に型付けする ◦ compilerOptions の strict オプションを true に

    ◦ @typescript-eslint/eslint-plugin の利用 ◦ ts-migrateは利用しない • fetch周りなど重要なロジックを優先して対応する • 新規の開発では必ずTypeScriptで実装する TypeScript化:実装方針
  15. 49 改善:コードレビューの負荷が大きい • 単体テスト・UIテスト ◦ Jest, Mocha, React Testing Library

    • CIでのチェック ◦ Lint ◦ テスト ◦ パフォーマンスバジェット:https://github.com/ai/size-limit • Storybook ◦ PRごとのPreview
  16. 52 改善:ビルドとデプロイに時間がかかる • Webpack のバージョン更新 ◦ v3 → v4 •

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

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