import { NextRequest, NextResponse } from 'next/server';
import { revalidateTag } from 'next-cache';
export async function POST(request: NextRequest) {
const secret = request.nextUrl.searchParams.get('secret');
const tag = request.nextUrl.searchParams.get('tag');
if (secret !== process.env.REVALIDATION_TOKEN) {
return NextResponse.json({ message: 'Invalid token' }, { status: 401 });
}
if (!tag) {
return NextResponse.json({ message: 'Missing tag' }, { status: 400 });
}
try {
revalidateTag(tag);
return NextResponse.json({ revalidated: true, now: Date.now() });
} catch (err) {
return NextResponse.json({ message: 'Error revalidating' }, { status: 500 });
}
}Salutare! Văd des pe forum discuții despre cum să cache-uiești paginile în Next.js și mulți se blochează în clasicul „punem ISR la 60 de secunde peste tot”. Am pățit asta la un proiect e-commerce cu vreo 12.000 de produse, unde am reușit să reducem timpul de build cu 75% doar regândind strategia asta. Hai să vedem cum le așezăm corect în App Router.
De ce e greu să alegi din prima?
Pe hârtie, totul sună simplu: SSG e rapid, ISR e flexibil, SSR e dinamic. În realitate, când ai mii de pagini și date care se schimbă la secunde sau la săptămâni, decizia greșită te costă bani pe servere sau nervi de la clienți care văd prețuri vechi.
Am învățat pe propria piele că dacă lași Next.js pe setările default de caching, te trezești cu memory leaks sau cu pagini care nu se mai updatează deloc din cauza CDN-ului din față.
Cele 5 scenarii din producție
1. Pagina de produs (E-commerce cu trafic mare)
Soluția: ISR cu timeout generos (ex. 1 oră) + Client-side fetch pentru stoc. Nu are rost să revalidezi toată pagina de produs la fiecare minut dacă doar stocul se schimbă. Noi am generat paginile static la build (doar top 500 cele mai vândute), iar pentru restul am lăsat ISR la 3600 de secunde. Pentru stoc și preț real, facem un fetch rapid direct din browser.
2. Pagina de checkout sau coș de cumpărături
Soluția: SSR pur (force-dynamic / no-store) sau Client-side rendering.
Aici n-ai ce să cache-uiești. Datele sunt 100% dinamice și specifice fiecărui utilizator. Orice formă de cache aici înseamnă riscul uriaș ca userul A să vadă adresa sau cardul userului B.
3. Blogul companiei sau pagini de marketing
Soluția: SSG la build + On-demand revalidation prin Webhooks. Editorii scriu un articol o dată pe săptămână. De ce să pui ISR la 10 minute? E complet inutil. Am configurat un webhook în headless CMS care apelează un endpoint de revalidare din Next.js doar când se dă „Publish”. Build-ul e instant la accesare, iar cache-ul e mereu proaspăt.
4. Dashboard-ul de user (SaaS)
Soluția: Client-side fetching cu SWR sau React Query. Pagina în sine poate fi un shell static (SSG), dar datele (grafice, setări, facturi) sunt aduse direct din API pe client. Evită SSR-ul greoi aici dacă vrei ca interfața să se simtă instantanee.
5. Pagina de Termeni și Condiții
Soluția: SSG pur (Static complet). Se schimbă o dată pe an. O lași să se genereze la build și uiți de ea. Nu are nevoie de nicio strategie de revalidare dinamică.
Trade-off-ul ascuns din spatele ISR
ISR-ul este excelent, dar are o problemă: primul user care intră după expirarea timpului de cache va vedea tot pagina veche (stale). Next.js va declanșa regenerarea în fundal, iar abia al doilea user va vedea pagina nouă. Dacă ai un spike de trafic exact când expiră cache-ul, s-ar putea ca serverul tău de Node să fie înecat de request-uri de regenerare.
Pentru a evita asta, pe proiectele mari mergem aproape exclusiv pe On-demand revalidation folosind tag-uri de cache.
Cum arată codul pentru On-demand revalidation
În App Router, ne folosim de revalidateTag în interiorul unui Route Handler. Iată exemplul clasic pe care îl apelăm din CMS când se modifică un produs. Tot ce trebuie să facem e să trimitem un request POST securizat cu o cheie secretă ca să nu ne poată goli oricine cache-ul.