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 body = await request.json();
const productId = body.productId;
if (productId) {
// Ștergem cache-ul doar pentru produsul modificat
revalidateTag(`product-${productId}`);
return NextResponse.json({ revalidated: true, now: Date.now() });
}
return NextResponse.json({ revalidated: false });
}Salutare. M-am lovit recent de o discuție aprinsă cu un client care voia ca paginile lui să se încarce instantaneu, dar datele să fie actualizate la secundă, fără delay. În Next.js App Router, mulți încă se încurcă între SSG, ISR și on-demand revalidation, deși decizia e destul de simplă dacă o privești prin prisma arhitecturii de date.
La un magazin online cu peste 14.000 de produse active pe care l-am migrat anul trecut, am redus timpul de build pe Vercel de la 28 de minute la doar 3 minute. Cum? Am renunțat la generarea statică completă (SSG) pentru toate produsele și am trecut pe o combinație strânsă de ISR și on-demand revalidation.
Hai să trecem direct la cele 5 cazuri concrete pe care le întâlnești în viața de zi cu zi.
1. Pagini ultra-statice (Termeni și condiții, Despre noi)
Aici decizia e simplă: SSG (Static Site Generation). Datele se schimbă extrem de rar, de obicei doar când intervine departamentul legal.
- Cum funcționează: Next.js randează pagina la build-time și o servește direct din CDN. Zero interogări la baza de date în producție.
2. Blog de companie sau știri (ISR pe timp)
Dacă ai un blog unde se publică câteva articole pe zi, nu are sens să rebuild-uiești tot site-ul pentru o virgulă corectată. Aici folosești ISR (Incremental Static Regeneration) cu interval de timp.
- Setare: Adaugi
export const revalidate = 3600(o oră) în layout sau pagină. - Trade-off: Primul user care intră după ce expiră ora va vedea tot pagina veche, dar va declanșa regenerarea în fundal. Al doilea user va vedea varianta nouă. E un compromis excelent pentru că salvezi mii de request-uri către baza de date.
3. Pagina de produs în E-commerce (On-Demand Revalidation)
Aici e jocul cel mai periculos. Dacă modifici prețul în ERP sau în CMS, vrei ca userul să îl vadă instant, nu după o oră și nici nu vrei să aștepți jumătate de oră după un build complet.
- Soluția: On-demand revalidation folosind tag-uri de cache (
revalidateTag). - Flux: Când un produs se modifică în baza de date, trimiți un webhook simplu către o rută de API din Next.js care șterge cache-ul doar pentru acel produs. Pagina rămâne statică în restul timpului, oferind performanță maximă.
4. Pagina de listare produse cu filtre complexe (Dynamic SSR)
Când ai zeci de filtre de preț, mărime și sortare, caching-ul static devine imposibil. Numărul de combinații e prea mare.
- Soluția: SSR pur (Server-Side Rendering) sau direct randare pe client (SPA style) dacă datele nu contează pentru SEO. Next.js va randa pagina la fiecare request.
5. Dashboard-ul privat al utilizatorului (Client-side fetching)
Datele financiare sau setările de cont ale utilizatorului nu au ce căuta pe un CDN public.
- Soluția: Folosești
force-dynamicsau faci fetch direct din client-side (cu SWR sau React Query) cu token-ul de sesiune. Zero cache pe server.
Voi ce strategie folosiți cel mai des la proiectele voastre? Eu am început să evit ISR-ul bazat pe timp și merg aproape exclusiv pe on-demand revalidation prin tag-uri, mi se pare mult mai predictibil pentru clienți.