ISRとRSCの選択に関する検討

[kei615ykhm]

概要

アプリケーションのコア機能の実装方法について、ISR（Incremental Static Regeneration）とRSC（React Server Components）のどちらを採用するか検討中です。両者にはそれぞれ特徴があり、判断に迷っています。

各ルーティング設定のメリット

ISRのメリット：

1. 静的生成と動的更新のバランスが取れている
2. 定期的な再生成により、データの新鮮さを保ちつつ、高速なページロードが実現できる
3. CDNキャッシュを活用でき、グローバルな配信に強い

RSCのメリット：

1. サーバーサイドでレンダリングを行い、必要最小限のJavaScriptをクライアントに送信できる
2. データフェッチをサーバーサイドで行えるため、APIキーなどの秘密情報を守りやすい
3. 動的コンテンツの扱いが柔軟で、リアルタイム性の高いアプリケーションに適している

このアプリケーションの特性

• 短い文章や気づきを素早くマークダウンで記録し、後で整理・関連付けを行う
• 将来的にメモの作成や編集がリアルタイムで行われる可能性が高い
• ユーザーごとに異なるコンテンツを表示する必要がある
• 個人学習目的の開発で、大規模リリースの予定はなく、同時接続は最大3人程度を想定
• 当面はSupabaseの無料枠内での運用を予定
• オフライン対応の予定なし

開発環境と技術的考慮事項

• ISR、RSCともに実践経験なし
• Next.js14の安定版App RouterやParallel Routesなど、新しい技術の学習が必要
• Supabase Authenticationを使用し、zodとreact-hook-form`で堅牢なログインフォームを実装予定
• 使用する技術の多くはudemyで学んだことを土台に少しアレンジを入れる程度
• 基礎的な概念や知識の理解を最優先とする
• 優先度が高い機能＋中優先度1～2件の実装を終えて動く形にするまでに最大で4～５ヶ月を想定

検討事項

1. これらの特性を考慮すると、ISRとRSCのどちらがより適していると思われますか？
2. パフォーマンスや開発効率の観点から、どのようなトレードオフがあると考えられますか？
3. ページの特性に応じてISRとRSCを使い分けるハイブリッドなアプローチも考えられますが、メモアプリという特性上、どのように実装すべきでしょうか？

提案

現状を踏まえ、ハイブリッドアプローチを提案します：

1. ISRの活用:

   • 静的なページ（ランディングページ、ヘルプページなど）
   • 更新頻度の低いコンテンツ（ユーザープロフィールなど）

2. RSCの活用:

   • メインのダッシュボード
   • メモ作成・編集ページ
   • リアルタイムでの更新が必要な箇所

このアプローチのメリット

• パフォーマンスと即時性のバランスが取れる
• 学習コストを抑えつつ、両方の技術に触れられる
• 将来的な拡張性を確保できる

ただし、学習コストを考慮すると、最初はISRを中心に実装し、徐々にRSCを導入していく方法も検討しています。

[kei615ykhm]

おもしろい案かもしれませんが、少し状況を見直してみましょうか。

1. 個人の学習が主な目的で、基礎部分の理解を優先したい
2. 当面の間は同時に使う人数は最大で３名程度
3. Supabaseはとりあえず無料枠で運用する
4. 開発期間は４～５か月（理解を含めて）
5. 使う技術のほとんどはUdemyで勉強したものがベース

それに対して、ISRとRSCは比較的新しく難しい技術になります。基本的な概念を理解するのであればSSRとSSGのほうが最適かもしれません。開発期間も４～５か月しかないのであれば、基礎を押さえることに注力すべきでしょう。あと、ISRではデータベースへのアクセスが増えてしまいますし、SSRは必要な時だけアクセスするので無料枠で運用する今回のケースに適してる思います。

これらを踏まえて、以下のようにするのはどうでしょうか？

SSR+一つのチャレンジとSSGで基礎は確実に押さえる

1. ダッシュボード: SSR + Parallel Routes

   • 最新のメモ一覧を見せるならSSRがいいかも
   • Parallel Routesで色んな情報を同時に表示できる
   • ダッシュボードは将来的に動的な要素を追加できるかも

2. メモページ（個別のメモ）: SSG

   • 一度作ったメモってそんなに頻繁に更新しないですよね
   • パッと開いてすぐ書けるようにしておきたい

3. メモ作成フォーム: SSR

   • 新しいメモを作るとき、最新の状態を反映させたいですよね

現在の開発状況と、学習曲線、ニーズに合わせるのであれば、「リアルタイムでメモを更新する」というのは外部メモアプリのAPIを使用することになるので未来の話です。今は「思いついたらすぐにメモ」が主な使い方だと思うのでSSR+SSGで十分じゃないでしょうか。

将来的なことを考えてISRを選びたいのなら、必要になったときにSSRから移行すれば良いです。

@niaka3dayo この提案は、いかがでしょうか？

[niaka3dayo]

まず、ISRとRSCは一緒に使うものです。 ISRとRSCどちらを使うかという考えは根本的に間違っていて、SSRも、ISRもRSCをどのように扱うかという描画の方法のことです。 おそらく、あなたがRSCとISRを同列のものだと勘違いしてAIに質問したことでハルシネーションが起きていると推測します。

Next.jsでは、要件や目的に応じて、SSR,ISR,SSG,CSRのどれを使うかをRSCごとに選択していきます。

SSG

SSGは、ビルドする時にそのビルドの過程でサーバーからデータをフェッチし、そのあとは一切データが変わりません。 つまり、データベースにメモのデータがあったとして、それを更新したり、追加しても、再度ビルドするまでは一切更新が反映されません。

SSR

SSRは、アクセスされるたびにサーバー側でフェッチを走らせ、最新の情報を取得します。SSGに比べると当然、サーバーがフェッチしている間のロードが発生するため、キャッシュ戦略や、初回フェッチしている間ユーザーに何を見せるかも重要です。フェッチに時間がかかれば画面が止まって見えます。

ISR

ISRは、SSGとSSRの合体技みたいなものです。指定した秒数以上アクセスがなかったら、SSGしなおして、また指定した秒数以内であれば更新せずに前のデータを返します。ユーザーからのアクセスに間が空いている場合、定期的にSSGするようなものです。

CSR

ここまでのデータフェッチ方法は全てサーバーにフェッチさせるものでした。 CSRは、アクセスがあった時にブラウザ側（クライアントサイド）でデータフェッチを行い、フェッチが終わったら状態を更新して再描画することで常に最新のデータを表示するものです。

選択の基準

個人的には、ログインして使うようなアプリでSEOを加味しない場合は全てCSRでいいと思います。 どうしてもサーバーコンポーネントで処理させたいならSSRでしょう。メモアプリは、たとえばPCでしたメモがすぐにケータイで見たとき反映されてないというのはだいぶ困ると思うので、情報の信頼性（最新かどうか）は重視するべき点と考えます。

なので、確実に最新の情報をもってくるCSRが最初に選択肢に上がり、時点でSSRが選択肢に上がるかなと思います。 SSGを選択する場合は、更新のたびにWebhookなどをたたいてビルドをし直す仕組みが必要となります。 メモに表示に時間がかかるような膨大なデータを単体ごとに使うことは考えにくいので、私ならSSGは真っ先に選択肢から除外します。 ISRも同様で、たとえば3分ごとに時間を設定したとして、3分前のデータが表示される可能性がある以上、メモアプリの仕様としては欠陥になると思います。

データベースのアクセス数を気にするのはそのアプリを使うユーザーが何人の想定かによっても変わると思いますが、個人用のメモアプリでデータベースのパフォーマンスが落ちるほどアクセスが集中するとも考えにくいです。

SSGを選択した場合にはメモが更新されるたびにサーバーでビルドを走らせなきゃならないので、その場合はデータベースのアクセス回数は減ってますがサーバー自体のコストは増えてますよね。

データベースへのアクセス回数を減らしつつ最新の情報を取得したいのであれば、CSRで行いつつ、ブラウザ側でのキャッシュ戦略を練るのが最善と考えますがいかがですか？

[niaka3dayo]

上記コメントを加味した上での設計の修正案です。

ダッシュボード(メモ一覧ページ): CSR

キャッシュ: SWRなどを使ったキャッシュを使用

メモの一覧を表示するページ。 確実に最新のメモ一覧を見せることができるよう作成。 ペジネーションにも対応させる。 ログアウトボタン・ページ遷移メニューなども。

個別メモページ: CSR

キャッシュ: SWRなどを使ったキャッシュを使用

単体の最新メモを閲覧する機能をもつページ。 ユーザー体験を考えれば、確認するだけでればモーダル(ダイアログ)で作り、ページ遷移はさせないことも検討余地あり。

メモ作成フォーム: SSG

フォーム自体に更新機能まで持たせる場合はCSRでデータをフェッチする。 しかしながらフォーム自体の形は毎回同じなので基本的にフォーム本体はSSGで描画される。

[kei615ykhm]

@niaka3dayo 詳しく教えていただき、ありがとうございます。

お返事が遅れてしまい申し訳ございません。ご指摘いただいた通り、AIによるハルシネーションを起こしている部分の訂正と不足している知識を補完してきました。 そして今度は、ご提案いただいた「CSRとSWRを用いたクライアントサイドでのキャッシュ戦略」について、私からも再提案・意見交換させていただきたいと思います。

議題が変わりますので、こちらのissueはクローズしますね。 issue: #7 にて、改めてアサインいたします。