// 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: 'Token invalid' }, { status: 401 });
}
const tag = request.nextUrl.searchParams.get('tag');
if (!tag) {
return NextResponse.json({ message: 'Lipsește tag-ul' }, { status: 400 });
}
// Revalidăm cache-ul instant pentru toate fetch-urile marcate cu acest tag
revalidateTag(tag);
return NextResponse.json({ revalidated: true, now: Date.now() });
}Am trecut prin toate fazele cu Next.js. De la vremurile când SSG-ul ne ținea build-ul blocat câte 25 de minute la fiecare deploy, până la ISR-ul clasic care servea pagini vechi clienților fix când schimbam prețurile în magazin. Dacă lucrezi la un proiect cu mii de pagini, decizia asta îți dictează direct factura de serverless și fericirea userilor.
Nu există o soluție magică, dar există decizii luate corect. Hai să vedem cum stă treaba în producție, dincolo de marketingul celor de la Vercel.
5 cazuri reale și decizia din spatele lor
1. Pagini legale și Termeni și Condiții (SSG Pur)
- Frecvență modificări: O dată la 6 luni.
- Strategia: Static Site Generation (
force-static). - De ce: Nu ai nevoie de dinamică aici. Pagina se generează la build, stă în CDN, costă zero ca execuție. Dacă se schimbă ceva, un deploy de 2 minute nu omoară pe nimeni.
2. Blog de companie sau site de știri (ISR Clasic pe bază de timp)
- Frecvență modificări: Câteva articole pe zi.
- Strategia: ISR cu
revalidate: 3600(o oră). - De ce: La un proiect cu 15.000 de articole, e o nebunie să le generezi pe toate la build. Generăm doar cele mai citite 100 de articole static, iar restul primesc build la prima accesare (fallback) și se actualizează în background o dată pe oră.
3. Pagina de produs în E-commerce (On-demand Revalidation)
- Frecvență modificări: Oricând se schimbă stocul sau prețul în ERP.
- Strategia: On-demand ISR folosind
revalidateTag()saurevalidatePath(). - De ce: Aici am pățit-o grav. Cu ISR la 60 de secunde, userii vedeau produse "în stoc", deși stocul se epuizase. Cu on-demand, legăm un webhook din ERP-ul clientului. Când se modifică stocul, trimitem un POST către Next.js și ștergem cache-ul instant doar pentru acel produs. Am redus timpul de build cu 70% la un magazin cu 12.000 de produse.
4. Dashboard-ul de client (SSR sau Client-side Fetching)
- Frecvență modificări: Secundară (date specifice userului).
- Strategia: Dynamic Rendering (
force-dynamic) sau direct apeluri API din React (useSWR/TanStack Query). - De ce: Caching-ul pe server nu are sens aici. Datele sunt private, se schimbă des și trebuie să fie ultra-proaspete.
5. Landing page de campanie cu stoc limitat (Hibrid)
- Frecvență modificări: Foarte rapidă în timpul campaniei.
- Strategia: SSG pentru layout-ul greu + un apel API separat pentru numărul de bilete/produse rămase.
- De ce: Dacă faci revalidare la fiecare secundă sub un trafic de 5.000 de useri concurenți, îți îngenunchezi baza de date. Mai bine livrezi layout-ul instant din CDN și încarci stocul cu un loader mic pe client.
Trade-off-ul sincer: Ce nu-ți spune Vercel
On-demand revalidation sună perfect pe hârtie, dar vine cu un cost de complexitate. Trebuie să-ți construiești un mecanism de retry în backend-ul tău în caz că webhook-ul de revalidare dă fail (500 sau timeout). Dacă webhook-ul pică, userii tăi vor vedea date vechi până la următorul deploy.
De asemenea, pe infrastructură proprie (Self-hosted Next.js pe Docker/Kubernetes), ISR nu funcționează out-of-the-box la fel de frumos ca pe Vercel dacă ai mai multe replici (pod-uri). Cache-ul se salvează pe disc local, deci o replică poate avea pagina veche, iar alta pagina nouă. Ai nevoie de un cache handler custom cu Redis ca să sincronizezi totul.
Tu ce strategie folosești cel mai des pentru paginile cu conținut dinamic?