このページは、Next.jsのrevalidateTagとrevalidatePathに関する整理メモです。
前提として押さえておきたい情報
そもそもrevalidateというのは、Webに昔からある概念。 詳細を深ぼるとCache-Control ヘッダーやキャッシュの議論にも行き着く。
上記のNoteに示した通り、このCache-Controlで使用できるディレクティブの中には、、*-revalidateのようなものがある。ここでは詳細には書かないが、これらはいわゆる再検証を意味し、must-revalidateであれば、max-ageとともに併用され、キャッシュの時間的鮮度に応じて再検証の必須（再検証しないと再利用不可）を意味し、stale-while-revalidateであれば、キャッシュが古くなった場合に再検証必要になった場合、設定した期間分古いキャッシュを再利用できます。
このように、revalidateは再検証および・これまでの古いキャッシュの扱い（再利用・破棄）に関連する概念といえると思います。
Next.jsのISR
ISRとは、Next.jsが提唱したIncremental Static Regenerationの略です。今回は端的に表現するとSSGやSSRのデメリットを解決できるかもしれない仕組みとします。
デメリットというのは、たとえばSSGだと基本的にプロジェクト全体を再ビルドすることで、HTMLファイルなどを生成します。WebhookによるSSGワークフローであれば、hook受信後にプロジェクト全体を再ビルドしCDNなどにキャッシュすることに、無事ブラウザに描画するためのファイルを届けています。
しかし、プロジェクトの規模が肥大化すればするほど、プロジェクト全体を再ビルドするとビルドに時間がかかったり、サーバーに負担がかかったりする可能性があります。
SSRは、パーソナライズする画面やリアルタイムでのコンテンツ描画が必要な場合に用いられます。これも非常に便利な仕組みですが、リクエスト数によっては、サーバーに負荷が膨大にかかります。
その上で、既存のレンダリング（SSG/SSRなど）のデメリットを、場合によっては代替できる仕組みとしてISRというものがあると思っています。
感じ方には個人差あると思いますが、どちらかというと多少の遅延が許されるSSGで実現するような静的寄りなプロジェクトをより効率よく運用する仕組みとしてISRは非常に便利だなと個人的には感じています。（よくWebhookを用いてOn-demand ISR（後述）を実装したりします）
そしてISRには、大きく分けて以下の2つが存在します。
- Time-based revalidation
- On-demand revalidation
ざっくり説明すると、
Time-basedは、時間的に再検証（ブラウザ標準のmax-ageのように7日とか、設定するイメージ）を促すISR、On-demandは、何かしらのトリガー（たとえば、CMSからのWebhook通知とかのイメージ）をもとにライブで再検証を促すISRになります。
今回整理する、revalidateTagとrevalidatePathの2つは、後者のOn-demand revalidationのような実装時に使用できるNext.jsのAPIになります。
revalidatePath
revalidatePathは、ルートごとにキャッシュを無効化する仕組みです。
Server ActionおよびRoute Handlerで呼び出すことができます。（基本的にサーバーで処理されるので、クライアントでは使えません）
Pathの名の通り、以下のようなものを無効化できます。
- ページ
- レイアウト
- Route Handler
個人的には、以下のようにRoute HandlerでCMSなどのWebhookをトリガーとしてページや特定のURLなどのキャッシュ無効化と再検証などに使用することが多いです。
import { revalidatePath } from 'next/cache'
revalidatePath('/blog/post-1')revalidateTag
revalidateTagは、キャッシュタグが付与されたコンテンツのキャッシュを無効化する仕組みです。
疲れたので一旦休憩。
また、updateTagというのもありますが、後ほど調べて書き加えておきます。