React フレームワークの 動向と選定基準

まずはじめ React に焦点を置き、昨今のフロントエンドでどのようなフレームワークが選択肢にあげられるのかについて紹介します。続いて、技術選定を行う際に、どのようなことを考えるべきかについて話します。最後にこれまで話した点を踏まえて、私が実際に技術選定を行った際にどのような選択をしたのか実践的な内容について触れたいと思います。

Transcript

1. React フレームワークの 動向と選定基準 azukiazusa
2. 自己紹介 • Web アプリケーションエンジニア • Web フロントエンドが得意 • https://azukiazusa.dev • 趣味 ◦ 読書 ◦ 麻雀 ◦ ポーカー azukiazusa
3. アジェンダ • メジャーな React フレームワークの紹介 • 技術選定時に考えるべきポイント • 実際にどのような選択をしたのか • まとめ
4. アジェンダ • メジャーな React フレームワークの紹介 • 技術選定時に考えるべきポイント • 実際にどのような選択をしたのか • まとめ
5. React プロジェクトに フレームワークは必要？
6. ほとんどのサイトやアプリケーションで 必要な機能の再発明を防ぐ • ルーティング、データ取得、コード分割... ◦ React は UI ライブラリである • React の公式ドキュメントでもフレームワークを使うこ とが推奨されている https://ja.react.dev/learn/start-a-new-react-project
7. React で新しいプロジェクトを 始める場合を想定
8. フレームワークを使わない選択肢が 全く否定されるわけではない • 既存プロジェクトに React を追加する • 社内向けのツール
9. React フレームワークの紹介 • Next.js（Pages Router） • Next.js （App Router） • Remix • Remix（SPA モード） • React + Vite（バンドラー） • Gatsby • Astro
10. Next.js（Pages Router） • Next.js v13 以降で登場した App Router に対して Pages Router と呼ばれる ◦ Pages Router が非推奨というわけではない • ページごとに SSR・SSG・ISR の中からレンダリング方 式を選択できる
11. Pros • 画面ごとのパフォーマン スの最適化 • 枯れたフレームワークと 言える • <Image /> などの様々 な最適化 • 動的なページを必要とす る SPA には向いていな い • ISR を採用する場合、イ ンフラが制限される Cons
12. Next.js（App Router） • Server Components や Streaming、Server Actions の ような React の最新の機能をいち早く使える ◦ React Canary: Meta 外での段階的な新機能導入 https://ja.react.dev/blog/2023/05/03/react-canaries • よりよいユーザー体験を追求できる
13. Pros • 最新の機能を利用でき、最も 高いユーザー体験を提供でき る • デフォルトでリクエストの キャッシュ、重複排除機能が 備わっている • コロケーションパターンを採 用しやすい • 運用する難易度高い • キャッシュの仕様が難解 • undocument な挙動も 多く、ソースコードを読 み解く覚悟が必要 • エコシステムが整ってい ない Cons
14. Remix • 比較的新しめなフレームワーク • レンダリング方式は SSR または SPA • Web 標準の API に従うという設計哲学
15. Pros • Web 標準の API を採用 しているため、学習コス トが比較的緩やか • フィーチャーフラグによ るリリースの安定 • Next.js（Pages Router）と比較して採 用事例はまだ多くない • ISR やリクエストキャッ シュのような高度な機能 は提供されていない Cons
16. Remix（SPA モード） • 最近 Stable になった • React + React Router + Vite の延長のような使いごこち • Remix の既存の API をほぼ利用できる
17. Pros • インフラは静的ファイルの配 信サーバー • SSR をしたくなったときに移 行しやすい • ルーティング、コード分割な どフレームワークに求めれら れる機能が揃えってる • ユーザー体験や SEO が 犠牲になる Cons
18. React + Vite • フレームワークを採用しない選択肢 • 現代ではバンドラとして Vite が採用されるのが主流 • サーバーを使わない SPA アーキテクチャを採用する場合 選択肢に入ってくる
19. Pros • サーバー運用コストや、 フレームワークの学習コ ストを抑えられる • 既存のバックエンドと統 合しやすい • ルーティングやデータ取 得のライブラリを統合す る作業を自分で行う必要 がある ◦ 結局独自のフレーム ワーク作って学習コス トの問題が発生しがち Cons
20. Gatsby & Astro • SSG に特化されたフレームワーク • 静的なドキュメントサイトが主な用途 • Gatsby は豊富なプラグインがあり、多くの設定ができる • Astro は正確には React のフレームワークではなく、UI ライブラリの一部として React を使える
21. アジェンダ • メジャーな React フレームワークの紹介 • 技術選定時に考えるべきポイント • 実際にどのような選択をしたのか • まとめ
22. 技術選定時に考えるべきポイント • プロダクトの特性 • プロジェクトの優先度 • 開発メンバーのスキルセット • 社内での採用事例
23. プロダクトの特性 • EC サイト？社内システム？BtoB 向けの SaaS？ • EC サイトでは LCP スコアが収益に直結する ◦ https://web.dev/case-studies/rakuten?hl=ja ◦ パフォーマンスの最適化のためにコストを払える • BtoB 向けの SaaS では App Router は too much になりがち ◦ パフォーマンスを重視する優先度は下がる ◦ 常に最新のデータを表示するため、キャッシュが全く不要
24. • フレームワークをリプレイスするような場合には、新規 の開発が止まってしまう恐れがある ◦ どのくらいの期間なら開発を止めてもいいか？ ▪ コードの書き換えの作業時間 ▪ メンバーへの教育コスト ◦ フレームワークの新しい機能を採用すると、プロダク トやチームにとってどんなメリットがあるか？ プロジェクトの優先度
25. • 専任のフロントエンドのエキスパートのみで構成されて いるチーム？ • メンバー全員がすべての領域を触っているチーム？ • 高度な機能を持つフレームワークを採用するにあたって 相応の教育コストがかかる 開発メンバーのスキルセット
26. • 社内の他のプロダクトですでに使われている？ ◦ 問題に直面した時に他チームの知見が使える ◦ メンバーの増員が必要になった時、同じフレームワー クを採用していれば Join しやすい • もしくは、社内で標準化されることを念頭に入れる 社内での採用事例
27. ある機能から享受できる利益と 発生するコストを天秤にかけて 考える
28. アジェンダ • メジャーな React フレームワークの紹介 • 技術選定時に考えるべきポイント • 実際にどのような選択をしたのか • まとめ
29. 前提条件 プロダクトの特性 • SaaS アプリケーション • キャッシュは不可能 • グラフの表示が主で、クライアント でデータを取得することが多い プロジェクトの優先度 • 多くの工数を割けない 開発メンバーのスキルセット • 開発メンバー全員がすべての領域 を触る 社内の採用事例 • Next.js（Pages Router）が多い
30. React + Vite を採用 • パフォーマンスは最優先事項ではない ◦ 開発メンバーに対する教育コストを払うに値する材料ではない • フレームワークのリプレイスに工数を割けない ◦ 既存のバックエンドと統合しやすいのがメリット • 社内のその他のプロダクトとは特性が異なるので、採用事例は重視 しなかった • 技術選定をした当時 Remix SPA モードは Stable ではなかった
31. プロダクトマネージャー（意思決 定者）を説得できる材料があるか を考えて言語化する
32. 意思決定をした際には 必ず文書化する
33. ADR と呼ばれる手法を採用 • ステータス • 問題 • コンテキスト • 決定 • compliance • 代替案
34. まとめ • React のメジャーなフレームワークの特性を紹介 • 技術選定をする際には、与えられた諸条件からある機能 を採用した際に享受できるメリットとコストを天秤にか ける • 意思決定者を説得できるだけの材料があるか？を考えて 言語化する • 意思決定した際のコンテキストや決定などを文書化する