Tweet
Tweet

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