// app/api/revalidate/route.ts
import { NextRequest, NextResponse } from 'next/server';
import { revalidateTag } from 'next/cache';
export async function POST(request: NextRequest) {
const secret = request.nextUrl.searchParams.get('secret');
if (secret !== process.env.MY_SECRET_TOKEN) {
return NextResponse.json({ message: 'Invalid token' }, { status: 401 });
}
const tag = request.nextUrl.searchParams.get('tag');
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 });
}
}M-am lovit recent de o discuție aprinsă cu un client care voia neapărat ca toate paginile din noul lui magazin online să fie ultra-rapide, dar și actualizate la secundă. Omul auzise el de SSG și voia să generăm static tot. I-am explicat că la 15.000 de produse, build-ul în CI/CD o să ruleze până ne prinde pensia.
Mulți deveri sar direct pe o soluție fără să pună în balanță costul de build și prospețimea datelor. Haideți să vedem cum stă treaba în realitate, pe baza a ce am implementat eu în proiecte reale.
Cele 5 scenarii din producție
1. Blogul sau site-ul de prezentare (SSG Pur)
Dacă ai un site unde scrii o dată pe săptămână, nu te complica. Folosește SSG (Static Site Generation). Paginile se generează la build time și gata.
- Trade-off: Dacă ai greșit o virgulă, trebuie să dai trigger la un build nou. Dar la 20 de pagini, asta durează sub un minut, deci nu-ți pasă.
2. Pagini de produs în E-commerce (ISR cu timp fix)
La magazinul de care ziceam, am mers pe Incremental Static Regeneration (ISR) cu un revalidate de 3600 de secunde (o oră). Primele 100 de produse cele mai vândute sunt generate la build, restul sunt generate la prima accesare (folosind dynamicParams = true în App Router).
- Cum a ajutat: Am redus timpul de build de la 45 de minute la sub 3 minute.
- Trade-off: Dacă schimbi descrierea unui produs în CMS, primul utilizator care intră pe pagină în acea oră va vedea tot varianta veche. Abia următorul o vede pe cea nouă.
3. Stocuri și prețuri dinamice (On-Demand Revalidation)
Prețul și stocul nu pot fi „vechi de o oră”. Riști să vândă omul ceva ce nu are pe stoc. Aici intervine revalidarea la cerere (on-demand via tag-uri sau căi).
Când administratorul modifică stocul în ERP, sistemul trimite un webhook către Next.js care apelează revalidateTag('produs-123'). Pagina se regenerează instant în fundal.
4. Dashboard de Analytics securizat (Fără SSG/ISR)
Am văzut pe unii că încercau să facă ISR pe pagini protejate de middleware. Nu faceți asta. Dacă datele sunt private și se schimbă des, folosiți randare dinamică pe server (SSR) sau, și mai simplu, fetch direct de pe client (SWR sau React Query) în spatele unui schelet de loading.
5. Documentație tehnică (SSG + GitHub Webhook)
Pentru documentații, cel mai curat e SSG complet, dar cu on-demand revalidation declanșat printr-un webhook din GitHub Actions. Când dai push în repo-ul de content, Next.js primește un ping și revalidează doar paginile modificate.
Diagrama rapidă de decizie
Ca să nu te mai pierzi în detalii, pune-ți trei întrebări simple:
- Datele sunt publice și identice pentru toți? Dacă NU -> mergi pe Client-side sau SSR.
- Datele se schimbă des sau depind de utilizator? Dacă NU -> mergi pe SSG.
- Volumul de pagini e uriaș? Dacă DA -> mergi pe ISR cu timp sau On-demand. Dacă NU -> SSG pur.
În final, cel mai bun setup pe care l-am rulat combină ISR-ul de siguranță (să zicem o revalidare la 24 de ore în caz că pică vreun webhook) cu On-Demand Revalidation pentru modificările critice din CMS.
Voi ce strategii folosiți cel mai des în App Router? V-ați lovit de probleme cu cache-ul blocat pe CDN-uri terțe?