import { NextRequest, NextResponse } from 'next/server';
import { revalidateTag } from 'next/cache';
export async function POST(request: NextRequest) {
const body = await request.json();
const productId = body.productId;
const secret = request.nextUrl.searchParams.get('secret');
if (secret !== process.env.MY_SECRET_TOKEN) {
return NextResponse.json({ message: 'Invalid token' }, { status: 401 });
}
if (!productId) {
return NextResponse.json({ message: 'Missing product id' }, { status: 400 });
}
// Revalidăm doar cache-ul pentru produsul modificat în ERP
revalidateTag(`product-${productId}`);
return NextResponse.json({ revalidated: true, now: Date.now() });
}Salutare! M-am lovit recent de o discuție aprinsă cu un client care voia 'totul în timp real', dar pe pagini statice generate la build. Haideți să lămurim când și cum să folosiți SSG, ISR sau On-demand revalidation în App Router, ca să nu vă mai treziți cu build-uri blocate în Vercel sau cu clienți care văd prețuri vechi de ieri.
La un proiect e-commerce de acum un an, cu peste 15.000 de produse, am făcut greșeala să pornim cu SSG pur. Rezultatul? Build-ul în CI/CD dura 38 de minute și pica constant din cauza API-ului de la ERP care nu ținea la atâtea request-uri simultane. Am economisit cam 90% din timpul de build după ce am trecut pe o strategie hibridă de ISR și on-demand revalidation. Am scăzut sub 2 minute.
Cele 5 scenarii reale din producție
Ca să nu vă mai pierdeți în documentația Next.js, am structurat decizia asta în funcție de dinamica datelor. Iată cum am împărțit lucrurile pe proiectele noastre:
1. Pagina de Termeni și Condiții (SSG pur)
Aici datele se schimbă o dată la un an, când vine echipa juridică cu update-uri. Folosim SSG clasic. Nu avem nevoie de revalidare automată. Când se schimbă ceva, dăm un push în git, se face deploy și gata.
2. Blogul companiei (ISR la 1-12 ore)
La articole de blog, timpul de propagare nu este critic. Dacă adaugi un articol nou sau modifici o virgulă, nu moare nimeni dacă apare pe site peste o oră. Am setat un interval de revalidare de o oră (3600 secunde). Avantajul e că baza de date nu simte niciun pic de load de la cititori.
3. Pagina de listă / Categorii de produse (ISR la 60 de secunde)
Aici produsele intră și ies din stoc destul de des, dar utilizatorul nu se supără dacă lista e decalată cu un minut. Folosind un ISR scurt (60 de secunde), paginile se încarcă instantaneu pentru useri, iar serverul face revalidarea asincron în fundal (stale-while-revalidate).
4. Pagina de detalii produs (On-demand Revalidation)
Aici e buba mare. Dacă un produs s-a epuizat, nu poți lăsa userul să-l adauge în coș doar pentru că ai cache de o oră. Dar nici nu vrei SSR pur la fiecare request pe 15k de pagini. Soluția? Generăm paginile static, dar le punem un tag de cache (ex: 'product-123'). Când ERP-ul ne trimite un webhook că stocul s-a schimbat, apelăm un API route în Next.js care șterge cache-ul doar pentru acel tag specific.
5. Dashboard-ul utilizatorului (Fără cache / Dynamic SSR)
Aici vorbim de date ultra-specifice: istoric comenzi, setări profil, coș de cumpărături. Orice formă de SSG sau ISR aici este o gaură de securitate sau un bug logic masiv. Folosim direct dynamic rendering cu cache-ul dezactivat pe fetch-urile sensibile.
Trade-off-ul sincer pe care nu-l scrie în docs
On-demand revalidation sună ca Sfântul Graal, dar are o problemă ascunsă: presiunea pe API-ul extern. Dacă ai un webhook de update stoc care rulează de 500 de ori pe minut (de la sync-ul ERP), Next.js va încerca să revalideze paginile constant în fundal. Am pățit ca API-ul nostru intern să intre în rate-limiting din cauza asta.
Pentru astfel de cazuri, un ISR de 30 de secunde combinat cu o verificare în client-side direct în checkout (la adăugarea în coș) este mult mai stabil și mai ieftin de rulat.
Voi cum gestionați stocurile sensibile în Next.js? Mergeți pe on-demand sau preferați să lăsați client-side-ul să facă treaba grea direct la interacțiunea cu userul?