import { revalidateTag } from 'next/cache';
import { NextRequest, NextResponse } from 'next/server';
// Route Handler: /api/revalidate
export async function POST(request: NextRequest) {
const secret = request.headers.get('x-webhook-secret');
if (secret !== process.env.CMS_WEBHOOK_SECRET) {
return NextResponse.json({ message: 'Token invalid' }, { status: 401 });
}
const body = await request.json();
const { productId } = body;
if (!productId) {
return NextResponse.json({ message: 'productId lipsă' }, { status: 400 });
}
// Invalidează doar cache-ul asociat acestui produs
revalidateTag(`product-${productId}`);
return NextResponse.json({ revalidated: true, now: Date.now() });
}Acum doi ani am comis o greșeală clasică pe un magazin online cu peste 40.000 de produse: am setat ISR pe timp (revalidate = 60) pe toate paginile de produs. În trei zile, boții de la Google au generat atâtea invocări în fundal încât factura de Vercel a sărit de 400$. M-am prins repede ce am greșit, dar lecția a fost clară: să pui ISR la întâmplare e o rețetă sigură pentru dezastru.
Nu există o tehnică „cea mai bună”. Fiecare abordare din Next.js vine cu un schimb la nivel de performanță, stocare și costuri de infrastructură.
1. SSG Pur (Static Site Generation)
Generare completă la build time. Zero server overhead la runtime, încărcare din CDN în sub 50ms.
- Când îl folosești: Pagini de aterizare, documentație, bloguri mici (sub 300-500 de pagini).
- Trade-off: Când modifici o singură literă, trebuie să dai redeploy complet. Dacă ai 10.000 de pagini, build-ul devine lent și enervant.
2. ISR bazat pe timp (Time-based ISR)
Paginile se generează o dată, iar după ce expiră timpul setat (ex: revalidate: 3600), următorul request servește varianta veche (stale), dar declanșează o revalidare în fundal pe server.
- Când îl folosești: Pagini de știri, feed-uri de articole sau directoare unde conținutul se schimbă des, dar nu e critic dacă un utilizator vede prețul vechi pentru câteva minute.
- Trade-off: Ai date învechite (stale content) pentru primul vizitator de după expirare. Boții de căutare pot genera build-uri inutile în fundal dacă îți navighează tot site-ul continuu.
3. On-Demand Revalidation (Webhook / Tag-based)
Paginile rămân statice în CDN până când aplicația primeste un eveniment din exterior (ex: un webhook din CMS sau un API call după o modificare de stoc în admin).
- Când îl folosești: E-commerce (când se schimbă prețul sau stocul unui produs), sisteme de management de conținut unde editorii vor să vadă modificările instant.
- Trade-off: Complexitate puțin mai mare în cod. Trebuia să configurezi webhook-uri sigure și să gestionezi tag-urile de cache corect (
revalidateTag).
Matricea decizională pe cazuri reale
Iată cum le împart eu de obicei pe proiecte reale:
- Blog personal sau Site de prezentare: SSG pur. Fără discuții, ieftin și rapid.
- Catalog E-commerce (10k+ produse): On-Demand Revalidation folosind
revalidateTag('product-id'). Pagina e statică până schimbi ceva în ERP/CMS. - Portal de Știri cu trafic uriaș: ISR pe timp scurt (
revalidate = 60). Protejezi baza de date de spike-uri de trafic. - Dashboard B2B / Admin Panel: Zero revalidation/SSG. Aici mergi direct pe Dynamic Rendering (SSR) sau fetch-uri pe client cu SWR / React Query. Datele trebuie să fie mereu proaspete și specifice fiecărui user logged in.
- Pagini de Căutare și Filtrare: Dynamic Server Rendering, eventual cu un cache la nivel de API route, altfel explodează numărul de pagini statice pe care le stochezi.
La proiectul menționat la început, trecerea pe On-Demand Revalidation cu revalidateTag a redus timpul de build de la 22 de minute la sub 45 de secunde, iar costurile au scăzut înapoi la planul gratuit.
Voi ce strategie folosiți cel mai des în App Router și unde v-ați lovit de limitări?