// 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');
const tag = request.nextUrl.searchParams.get('tag');
if (secret !== process.env.MY_SECRET_TOKEN) {
return NextResponse.json({ message: 'Unauthorized' }, { status: 401 });
}
if (!tag) {
return NextResponse.json({ message: 'Missing tag parameter' }, { status: 400 });
}
try {
revalidateTag(tag);
return NextResponse.json({ revalidated: true, now: Date.now() });
} catch (err) {
return NextResponse.json({ message: 'Error revalidating' }, { status: 500 });
}
}Salut. Am tot văzut confuzii pe Slack și prin comunitate despre când să folosești SSG, ISR sau on-demand revalidation în Next.js, mai ales de când cu App Router. Am trecut prin toate variantele astea pe proiecte reale și am decis să pun pe hârtie logica mea de decizie. Fără teorie inutilă, doar ce funcționează în producție și ce te arde la buzunar.
Cele 5 cazuri din viața reală
1. Blogul de companie sau site-ul de prezentare
Aici merg pe SSG (Static Site Generation) pur. N-ai de ce să te complici. Faci build-ul la deploy și gata. Dacă echipa de marketing adaugă un articol o dată pe săptămână, un nou build în CI/CD durează 2 minute și n-ai nicio bătaie de cap cu servere sau cache invalidat aiurea.
2. Catalogul de produse (10k+ repere)
Aici SSG-ul clasic moare. Am avut un proiect unde build-ul dura 22 de minute și pica constant din cauza memoriei pe serverul de CI. Am trecut pe ISR (Incremental Static Regeneration) cu un timeout de 12 ore (revalidate = 43200). Paginile se generează lazy, doar când sunt accesate de utilizatori, iar timpul de build a scăzut la sub 3 minute pentru că am randat static doar primele 50 de produse cele mai vândute.
3. Prețul și stocul pe pagina de produs
Aici ISR-ul bazat pe timp e periculos. Nu vrei ca un client să cumpere un produs cu 100 de lei când prețul real s-a modificat acum un minut în ERP la 150 de lei. Soluția pe care o folosesc mereu este On-demand Revalidation. Când se schimbă prețul în baza de date, trimit un webhook din backend-ul principal către Next.js și șterg cache-ul instantaneu folosind revalidateTag().
4. Dashboard-ul de utilizator (Analytics)
Aici caching-ul static e complet inutil. Datele sunt dinamice, private și se schimbă des. Mergi direct pe Server-side Rendering (SSR) (sau dynamic = 'force-dynamic') sau fetch direct din client (CSR) securizat cu un token. Nu vrei să riști ca datele financiare ale unui user să ajungă în cache-ul altui user.
5. Pagini legale (GDPR, Termeni și Condiții)
SSG cu on-demand manual. Le randezi complet static la build-ul inițial. Dacă avocații modifică un paragraf o dată pe an, apelezi manual un endpoint de revalidare din CMS-ul headless. Zero resurse consumate pe server în restul timpului.
Compromisul de care nu-ți spune nimeni
ISR are o problemă majoră de UX numită stale-while-revalidate. Când expiră timpul setat de tine (să zicem 60 de secunde), primul utilizator care intră pe pagină va vedea tot datele vechi. Next.js declanșează regenerarea paginii în fundal, iar abia al doilea utilizator (sau la următorul refresh) va vedea pagina actualizată.
Am pățit asta la un magazin online în timpul unei campanii de reduceri: clienții adăugau în coș produse crezând că sunt pe stoc, pentru că vedeau pagina generată acum 5 minute. Dacă ai date critice, nu te baza pe timp. Mergi pe revalidare bazată pe evenimente (on-demand), chiar dacă înseamnă un pic mai mult cod scris în backend.
Voi cum gestionați sincronizarea stocurilor în Next.js? Vă bazați pe ISR la intervale scurte sau ați implementat webhooks?