AI Session Notes - 2026-02-26
BFF（画面専用API）vs 汎用API の設計トレードオフ
学んだこと
- フロントエンドから複数の汎用APIを叩いてデータを組み立てるパターンは、ネットワーク遅延が積み重なりパフォーマンス劣化しやすい
- BFF（Backends For Frontends）として画面専用APIを用意すれば、1リクエストで必要なデータを返せるのでUX上有利
- ただし画面専用APIは、クライアントが増える（モバイルアプリ、管理画面など）と似たエンドポイントが増殖してバックエンドの負担が大きくなる
- 汎用APIは「必要なデータを返すエンドポイントがすでにある」ケースが生まれるため、フロントだけで完結する変更の割合が増える
- 実現手段は BFF・GraphQL・tRPC など複数あり、チーム構成やプロダクト規模で選ぶべき
SSR モノリス vs SPA の技術選定
学んだこと
- 「汎用API vs 画面専用API」の議論はフロントとバックをAPI で分離したことから生まれる痛みであり、SSR モノリスなら問題自体が発生しない
- Rails + ERB のようなSSRモノリスでは、コントローラーが画面に必要なデータを直接組み立てるため、実質的に「画面専用のデータ取得」を自然にやっている
- Hotwire（Turbo + Stimulus）の登場により、SPA的なインタラクションもSSRのまま実現できる範囲が広がっている
- 個人開発では「ユーザーに価値を届ける速度」が最優先であり、技術スタック選定で消耗するのはもったいない
- 「最初はSSRで始めて、APIが必要になったら足す」は立ち上げ期の合理的な戦略
モノリスからフロントエンド分離する段階的移行の痛み
学んだこと
- 移行は段階を踏むほど不可逆的に複雑さが増す：SSRモノリス → React埋め込み（同一リポ）→ リポジトリ分離 → 完全SPA化
- React 埋め込みまでは比較的低コストだが、リポジトリ分離から一気にハードルが上がる
- リポジトリ分離で発生する主な痛み：
- 認証・セッション管理の再設計（Rails のセッション/CSRFに乗れなくなる）
- ルーティングの二重管理（どのURLをどちらが返すか）
- デプロイの協調（API変更とフロント変更の順序依存）
- 開発環境の複雑化（ローカルで2サービス起動、CORS設定）
- 分離するなら中途半端に後から剥がすより、最初から分離前提で新規サービスとして立ち上げる方が結果的に楽なことが多い
React が必要になる判断基準
学んだこと
- React が必要になる根本的な理由は「ブラウザ側で管理すべき状態が複雑になったとき」
- React の本質的な価値は「状態が変わったら、関連する画面部分を自動で再描画する」こと
- ERB + Hotwire で十分なケース：CRUD操作、ページ遷移ベースのフロー、簡単なリアルタイム更新
- React が欲しくなるケース：エディタ系UI、リアルタイムチャット、地図操作、複雑なフォームなど「サーバーに毎回聞いてたら遅すぎる」操作
- 判断方法：参考にしたい既存サービスを触ってみて、ページ遷移ベースか、ページ遷移なしでグリグリ動くかを見る
- カードゲームのようなインタラクティブなアプリでは React が向いている。ただしゲームロジック（勝敗判定、ルール適用）はチート防止のためサーバー側に置き、クライアントは演出・アニメーション・即時フィードバックを担当する
参考リンク
メタ情報
- ツール: Claude Code
- 関連技術: Rails, ERB, Hotwire, React, BFF, REST API, GraphQL, tRPC, WebSocket