🐕
フロントエンドアプリケーションの動向
React単体では物足りない？
🎯 Reactはなぜ「単体」で使われなくなったのか？
Reactは「UIライブラリ」であり、アプリケーション全体を構成する仕組みは提供しません。
| 項目 | カバーするか？ |
|---|---|
| ルーティング | ❌（React Routerなどが必要） |
| 状態管理（大規模向け） | ❌（Redux, Recoilなどが別途必要） |
| SSR/SSG機能 | ❌（Next.jsなどが必要） |
| APIルーティング | ❌（Node.jsやHonoなどが必要） |
💡 結果として、**Reactは「フレームワーク」ではなく「部品」**として使われる傾向が強くなっています。
🚀 主なWebアプリの配信方式
サーバーサイドレンダリング（SSR）
- リクエストごとにHTMLをサーバーで生成し配信
- SEOや初期表示速度に優れる
- サーバーの負荷が高くなる
向いている用途: SEOを重視する動的Webサイト（例：メディア、EC）
静的サイト生成（SSG） / クライアントサイドレンダリング（CSR）
- ビルド時にHTMLを生成 or クライアントで描画
- CDNでの高速配信が可能
- 動的データにはAPI連携が必要
向いている用途: コンテンツ中心のWebサイト（例：ブログ、会社紹介）
🧰 代表的なフレームワーク7選
1. Next.js（Vercel製）
- SSR/SSG、APIルート対応
- App Routerの登場でさらに柔軟に
- 最も人気のあるReactフレームワーク
✅ オールインワン
⚠ 学習コストは高め
2. Hono（TypeScript製ミニマルWebフレームワーク）
- API構築に特化
- JSXを使えばUI構築も可能
- エッジランタイム（Cloudflare Workersなど）対応
✅ 超軽量、高速
⚠ UIは別途Reactなどが必要
3. Vite（高速ビルドツール）
- React/Vue/Svelteなど対応
- 開発サーバの起動とHMRが非常に速い
✅ 開発体験が快適
⚠ SSRやAPI機能は別途実装必要
4. Remix
- Web標準に準拠した設計（フォーム、ルーティング、fetch）
- SSR前提で高速・安定
- フルスタック対応
✅ Web標準に忠実
⚠ 学習コストや設計思想の理解が必要
5. Gatsby
- 静的サイト生成に特化
- GraphQLを使ったデータフェッチ
- CMSとの連携が得意（Contentful, Sanityなど）
✅ 高速な静的サイトに最適
⚠ GraphQLの学習が必要
6. Astro（コンポーネントアイランドアーキテクチャ）
- React/Vue/Svelteなどを併用可能
- 静的生成が得意、一部だけインタラクティブにする「島」構成
✅ JSバンドルが非常に軽量
⚠ フルスタック用途にはやや弱い
7. Expo（React Native向け）
- モバイルアプリ開発向けフレームワーク
- Web出力（
expo web）でReact Webアプリも構築可能
✅ モバイルとWebのコード共有が可能
⚠ 番外編（ネイティブアプリ寄り）
📊 フレームワーク比較表
| フレームワーク | SSR | SSG | API内蔵 | 特徴 |
|---|---|---|---|---|
| Next.js | ◎ | ◎ | ◎ | 万能型・大規模対応 |
| Hono | △（JSX利用時） | × | ◎ | 軽量APIサーバー向け |
| Vite | × | × | × | 開発体験特化 |
| Remix | ◎ | △ | ◎ | Web標準に忠実 |
| Gatsby | × | ◎ | △ | 静的サイト向け |
| Astro | △ | ◎ | × | 高速・軽量Webサイト向け |
| Expo | × | × | × | モバイル＋Web向け（React Native） |
🧩 なぜフロントエンドにAPI機能が必要なのか？
Reactをはじめとするフロントエンドアプリは、ユーザーの操作に応じてサーバーとやりとりを行う必要があります。
🔧 フロントエンドでAPIが必要な主な理由
- 🔄 データの取得・送信（例：ユーザープロフィール、商品リスト）
- 🔐 認証・認可（ログイン、トークン管理）
- 📦 外部サービスとの連携（例：Stripe、Firebase、CMSなど）
- 📈 リアルタイム通信や状態更新（WebSocket、ポーリング）
これらの機能をフロントエンドだけで完結するのは困難なため、APIとの連携が不可欠です。
🏗 BFF（Backend For Frontend）とは？
BFFとは、特定のフロントエンドに最適化された専用バックエンドのことです。
なぜBFFが必要？
- 🎛 UIと密接に結びついたデータ整形が必要（GraphQLなど）
- 🔒 認証トークンやセキュリティロジックの分離
- 🧩 複数の外部APIを統合・キャッシュ・加工したい
- ⚡ サーバー間の通信の最適化（モバイル向けなど）
🔍 BFFとして使える選択肢
| ツール/フレームワーク | 特徴 | 適した用途 |
|---|---|---|
| Next.js API Routes | Next.jsに内蔵、最小構成で済む | 小〜中規模アプリ向け |
| Hono / Express / Fastify | Node.jsベースの軽量APIサーバー | 高速・柔軟なBFF設計 |
| tRPC | 型安全なTypeScriptベースのRPC API | フロントエンドがTypeScriptなら相性◎ |
| GraphQL（Apollo, Yogaなど） | 柔軟なクエリとスキーマ駆動開発 | 複雑なデータ構造向け |
| Firebase Functions | サーバーレス＆Googleサービス連携に最適 | 簡易BFFやイベント駆動系 |
✅ API/BFF設計の観点から見るReactフレームワーク
| フレームワーク | API/BFF機能 | 説明 |
|---|---|---|
| Next.js | ◎（API Routes内蔵） | 小規模ならこれだけで十分 |
| Remix | ◎（loader/action） | SSRとフォーム送信に強いBFF代替 |
| Hono | ◎（Express代替） | API/BFF専用構成におすすめ |
| Vite | × | 別途APIサーバーが必要 |
| Gatsby | △（一部Functions） | 基本は静的向け、拡張で対応可能 |
| Astro | △（Server API有） | 島構成の補助的なAPI用途に向く |
🔐 認証・認可のレイヤー別責務（フロントエンド / BFF / API）
Webアプリケーションにおける「認証（Authentication）」と「認可（Authorization）」は、役割ごとに異なるレイヤーで分担されるのが一般的です。
🧭 認証 vs 認可の違い
| 概念 | 意味 | 例 |
|---|---|---|
| 認証（Authentication） | ユーザーが誰かを確認する | ログイン、トークン発行 |
| 認可（Authorization） | そのユーザーが何をしてよいかを制御する | 管理画面アクセス制限、機能ごとの権限管理 |
🧑🎨 フロントエンドの責務（Reactなど）
- 認証状態の保持と表示切替（UI制御）
- トークン（例：JWT、Session Cookie）の保存と送信
- ログインフォームやログアウト機能の提供
✅ UIの状態を制御（ログイン済/未ログイン）
⚠ 認証・認可ロジックそのものはフロントエンドに書かない
🧱 BFF（Backend For Frontend）の責務
- フロントエンドから送られたトークンの検証
- 外部APIやDBアクセス前のユーザー判定・制御
- 必要に応じて アクセストークンのリフレッシュ
- 認可ロジックの一元化とUIへのフィードバック
✅ フロントエンドに代わって「信頼できる」認証判定
⚠ BFFが信用できる前提でAPIとの橋渡しを行う
📦 APIサーバーの責務（BFF配下 or 外部API）
- 各リクエストのアクセストークンを厳密に検証
- リソース単位でのロールベース認可（RBAC）/属性ベース認可（ABAC）
- 多要素認証（MFA）やIP制限など、セキュリティ強化
✅ 最終的な「権限チェック」はAPIが責任を持つ
⚠ API単体でも不正アクセスを拒否できる設計が必要
🛡️ トークン管理と認証方式の実例
| 管理方式 | 保存先 | 特徴 | 主な利用例 |
|---|---|---|---|
| Session Cookie | Cookie（HttpOnly） | セキュア。自動送信、XSSに強い | Webアプリ（SSR）で主流 |
| Access Token（JWT） | localStorage / memory | API連携に便利。XSS対策が必要 | SPA、モバイルアプリなど |
| Refresh Token | Cookie（Secure, HttpOnly） | トークン更新に使う。漏洩注意 | 長期セッション維持向け |
💡 ベストプラクティス
- 認証処理はBFF or APIに責任を持たせる
- React側では「誰がログインしているか」をUIで表現
- API側ではスコープやロールに応じてアクセス制御
- フロント → BFF → API の連携時、責任境界を明確化する
📝 まとめ
- React単体では完結しない → 用途に応じたフレームワークの選定が必要
- SSR/SSG、API、ビルド方式などから選ぶと◎
- 迷ったらNext.jsを出発点に、**Hono（軽量API）やRemix（Web標準）**などを比較
Discussion