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

by azukiazusa

Embed

Start on current slide

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

自己紹介 ● Web アプリケーションエンジニア ● Web フロントエンドが得意 ● https://azukiazusa.dev ● 趣味 ○ 読書 ○ 麻雀 ○ ポーカー azukiazusa

Slide 3

Slide 3 text

アジェンダ ● メジャーな React フレームワークの紹介 ● 技術選定時に考えるべきポイント ● 実際にどのような選択をしたのか ● まとめ

Slide 4

Slide 4 text

アジェンダ ● メジャーな React フレームワークの紹介 ● 技術選定時に考えるべきポイント ● 実際にどのような選択をしたのか ● まとめ

Slide 5

Slide 5 text

React プロジェクトにフレームワークは必要？

Slide 6

Slide 6 text

ほとんどのサイトやアプリケーションで必要な機能の再発明を防ぐ ● ルーティング、データ取得、コード分割... ○ React は UI ライブラリである ● React の公式ドキュメントでもフレームワークを使うことが推奨されている https://ja.react.dev/learn/start-a-new-react-project

Slide 7

Slide 7 text

React で新しいプロジェクトを始める場合を想定

Slide 8

Slide 8 text

フレームワークを使わない選択肢が全く否定されるわけではない ● 既存プロジェクトに React を追加する ● 社内向けのツール

Slide 9

Slide 9 text

React フレームワークの紹介 ● Next.js（Pages Router） ● Next.js （App Router） ● Remix ● Remix（SPA モード） ● React + Vite（バンドラー） ● Gatsby ● Astro

Slide 10

Slide 10 text

Next.js（Pages Router） ● Next.js v13 以降で登場した App Router に対して Pages Router と呼ばれる ○ Pages Router が非推奨というわけではない ● ページごとに SSR・SSG・ISR の中からレンダリング方式を選択できる

Slide 11

Slide 11 text

Pros ● 画面ごとのパフォーマンスの最適化 ● 枯れたフレームワークと言える ● などの様々な最適化 ● 動的なページを必要とする SPA には向いていない ● ISR を採用する場合、インフラが制限される Cons

Slide 12

Slide 12 text

Next.js（App Router） ● Server Components や Streaming、Server Actions のような React の最新の機能をいち早く使える ○ React Canary: Meta 外での段階的な新機能導入 https://ja.react.dev/blog/2023/05/03/react-canaries ● よりよいユーザー体験を追求できる

Slide 13

Slide 13 text

Pros ● 最新の機能を利用でき、最も高いユーザー体験を提供できる ● デフォルトでリクエストのキャッシュ、重複排除機能が備わっている ● コロケーションパターンを採用しやすい ● 運用する難易度高い ● キャッシュの仕様が難解 ● undocument な挙動も多く、ソースコードを読み解く覚悟が必要 ● エコシステムが整っていない Cons

Slide 14

Slide 14 text

Remix ● 比較的新しめなフレームワーク ● レンダリング方式は SSR または SPA ● Web 標準の API に従うという設計哲学

Slide 15

Slide 15 text

Pros ● Web 標準の API を採用しているため、学習コストが比較的緩やか ● フィーチャーフラグによるリリースの安定 ● Next.js（Pages Router）と比較して採用事例はまだ多くない ● ISR やリクエストキャッシュのような高度な機能は提供されていない Cons

Slide 16

Slide 16 text

Remix（SPA モード） ● 最近 Stable になった ● React + React Router + Vite の延長のような使いごこち ● Remix の既存の API をほぼ利用できる

Slide 17

Slide 17 text

Pros ● インフラは静的ファイルの配信サーバー ● SSR をしたくなったときに移行しやすい ● ルーティング、コード分割などフレームワークに求めれられる機能が揃えってる ● ユーザー体験や SEO が犠牲になる Cons

Slide 18

Slide 18 text

React + Vite ● フレームワークを採用しない選択肢 ● 現代ではバンドラとして Vite が採用されるのが主流 ● サーバーを使わない SPA アーキテクチャを採用する場合選択肢に入ってくる

Slide 19

Slide 19 text

Pros ● サーバー運用コストや、フレームワークの学習コストを抑えられる ● 既存のバックエンドと統合しやすい ● ルーティングやデータ取得のライブラリを統合する作業を自分で行う必要がある ○ 結局独自のフレームワーク作って学習コストの問題が発生しがち Cons

Slide 20

Slide 20 text

Gatsby & Astro ● SSG に特化されたフレームワーク ● 静的なドキュメントサイトが主な用途 ● Gatsby は豊富なプラグインがあり、多くの設定ができる ● Astro は正確には React のフレームワークではなく、UI ライブラリの一部として React を使える

Slide 21

Slide 21 text

アジェンダ ● メジャーな React フレームワークの紹介 ● 技術選定時に考えるべきポイント ● 実際にどのような選択をしたのか ● まとめ

Slide 22

Slide 22 text

技術選定時に考えるべきポイント ● プロダクトの特性 ● プロジェクトの優先度 ● 開発メンバーのスキルセット ● 社内での採用事例

Slide 23

Slide 23 text

プロダクトの特性 ● EC サイト？社内システム？BtoB 向けの SaaS？ ● EC サイトでは LCP スコアが収益に直結する ○ https://web.dev/case-studies/rakuten?hl=ja ○ パフォーマンスの最適化のためにコストを払える ● BtoB 向けの SaaS では App Router は too much になりがち ○ パフォーマンスを重視する優先度は下がる ○ 常に最新のデータを表示するため、キャッシュが全く不要

Slide 24

Slide 24 text

● フレームワークをリプレイスするような場合には、新規の開発が止まってしまう恐れがある ○ どのくらいの期間なら開発を止めてもいいか？ ■ コードの書き換えの作業時間 ■ メンバーへの教育コスト ○ フレームワークの新しい機能を採用すると、プロダクトやチームにとってどんなメリットがあるか？プロジェクトの優先度

Slide 25

Slide 25 text

● 専任のフロントエンドのエキスパートのみで構成されているチーム？ ● メンバー全員がすべての領域を触っているチーム？ ● 高度な機能を持つフレームワークを採用するにあたって相応の教育コストがかかる開発メンバーのスキルセット

Slide 26

Slide 26 text

● 社内の他のプロダクトですでに使われている？ ○ 問題に直面した時に他チームの知見が使える ○ メンバーの増員が必要になった時、同じフレームワークを採用していれば Join しやすい ● もしくは、社内で標準化されることを念頭に入れる社内での採用事例

Slide 27

Slide 27 text

ある機能から享受できる利益と発生するコストを天秤にかけて考える

Slide 28

Slide 28 text

アジェンダ ● メジャーな React フレームワークの紹介 ● 技術選定時に考えるべきポイント ● 実際にどのような選択をしたのか ● まとめ

Slide 29

Slide 29 text

前提条件プロダクトの特性 ● SaaS アプリケーション ● キャッシュは不可能 ● グラフの表示が主で、クライアントでデータを取得することが多いプロジェクトの優先度 ● 多くの工数を割けない開発メンバーのスキルセット ● 開発メンバー全員がすべての領域を触る社内の採用事例 ● Next.js（Pages Router）が多い

Slide 30

Slide 30 text

React + Vite を採用 ● パフォーマンスは最優先事項ではない ○ 開発メンバーに対する教育コストを払うに値する材料ではない ● フレームワークのリプレイスに工数を割けない ○ 既存のバックエンドと統合しやすいのがメリット ● 社内のその他のプロダクトとは特性が異なるので、採用事例は重視しなかった ● 技術選定をした当時 Remix SPA モードは Stable ではなかった

Slide 31

Slide 31 text

プロダクトマネージャー（意思決定者）を説得できる材料があるかを考えて言語化する

Slide 32

Slide 32 text

意思決定をした際には必ず文書化する

Slide 33

Slide 33 text

ADR と呼ばれる手法を採用 ● ステータス ● 問題 ● コンテキスト ● 決定 ● compliance ● 代替案

Slide 34

Slide 34 text

まとめ ● React のメジャーなフレームワークの特性を紹介 ● 技術選定をする際には、与えられた諸条件からある機能を採用した際に享受できるメリットとコストを天秤にかける ● 意思決定者を説得できるだけの材料があるか？を考えて言語化する ● 意思決定した際のコンテキストや決定などを文書化する