Summary
この文書の要点
- SPA Modeは静的配信と相性が良いが、サーバーloaderは使えない。
- データ取得は外部APIかビルド時データに寄せる。
- 認証が必要なデータ取得はブラウザ側へ寄せ、公開ページはビルド時生成と相性を見る。
- fallback、メタタグ、エラー画面、キャッシュを静的配信前提で検証する。
どこが設計の難所か
小さな情報アプリや管理補助ツールでは、サーバーを持つほどではないが、Reactのルーティングや状態管理は使いたいことがあります。Remix SPA Modeはその中間にありますが、通常のRemixと同じ感覚で設計すると制約に当たります。
SPA Modeでは、リクエストごとのサーバー処理に頼れません。SEO、初期表示、認証、フォーム送信、環境変数の扱いは、静的配信の制約に合わせて設計する必要があります。
RemixのSPA Modeは静的配信しやすい一方、loaderの実行場所や初期HTMLの情報量が通常のSSR構成と変わります。既存のRemix感覚で設計すると、SEO、認証、エラー処理で想定外の差が出ます。
境界をどう切るか
静的に閉じる機能と外部APIへ逃がす機能を分けます。画面遷移やクライアント状態はRemixで扱い、永続化や認証が必要な処理は別APIに任せます。環境ごとの差分はビルド時設定として明示します。
設計では、公開情報、ログイン後情報、頻繁に変わる情報を分けます。公開情報はビルド時や静的JSONで扱い、ログイン後の情報はAPIから取得し、画面遷移時のloadingや失敗状態を丁寧に設計します。
実装で効く細部
Viteビルドで生成物を作り、配信側ではすべてのアプリ内パスをindex.htmlへfallbackします。外部APIのURLは公開してよい設定だけを埋め込み、秘密情報はクライアントに置きません。
Vite設定、ルーティング、fallback HTML、環境変数の露出範囲を確認します。APIクライアントはブラウザ実行を前提にし、CORS、Cookie、認証ヘッダーを静的配信ドメインとの関係で設計します。
- SSR前提のloaderで秘密情報を扱っていないか確認する。
- 初期表示に必要なメタタグが静的HTMLへ出るページと出ないページを分ける。
- API障害時の画面をroute errorだけに任せず、データ取得状態として扱う。
壊れ方を観測する
検証では、直接URLアクセス、ブラウザリロード、戻る進む、404相当の画面、API失敗時の表示を確認します。静的配信先で同じ挙動になるか、ローカルpreviewだけでなくコンテナや本番相当で見ます。
検証では、`vite preview`だけでなく、静的配信と同じfallback設定でリロード、深いURL、404、認証切れを確認します。初期HTMLのtitleやdescriptionも、検索流入が必要なページでは重要な確認点です。
捨てた選択肢とトレードオフ
SPA Modeは運用が軽い一方で、サーバーでの認証やデータ整形ができません。後から業務機能が増えそうな場合は、最初からAPI境界を設けておくと移行しやすくなります。
SPA Modeは配信を軽くできますが、初期表示やSEOでSSRより不利になるページがあります。すべてをSPA化するのではなく、公開コンテンツと業務アプリで配信方式を分ける方が合理的な場合があります。
現場に残す判断軸
Remix SPA Modeは、サーバーを持たないことを積極的に選ぶ構成です。何をクライアントに置き、何を外部APIに任せるかを決めれば、小さなアプリを軽く保てます。
SPA Modeは簡単な逃げ道ではなく、実行場所を変える設計判断です。どのデータをいつ取得するかを明確にすれば、静的配信の軽さとアプリの保守性を両立できます。
