import { NextResponse } from 'next/server';
import { revalidateTag } from 'next/cache';
// Endpoint apelat de CMS/ERP când se modifică un produs
export async function POST(request: Request) {
const body = await request.json();
const secret = request.headers.get('x-revalidate-secret');
if (secret !== process.env.MY_SECRET_TOKEN) {
return NextResponse.json({ message: 'Neautorizat' }, { status: 401 });
}
const productId = body.id;
if (productId) {
// Revalidăm doar cache-ul asociat acestui produs specific
revalidateTag(`product-${productId}`);
return NextResponse.json({ revalidated: true, now: Date.now() });
}
return NextResponse.json({ message: 'Lipseste ID-ul produsului' }, { status: 400 });
}Salutare! Văd des pe forumuri developeri care pun revalidate: 60 pe toate rutele din Next.js și speră să funcționeze perfect în orice scenariu. Am făcut și eu prostia asta în trecut la un magazin online cu vreo 12.000 de produse. Ne-am trezit rapid cu serverul de baze de date în genunchi și cu clienți furioși că vedeau prețuri diferite în listă față de pagina de checkout.
Hai să trecem peste teoria din documentație și să vedem cum am mapat strategiile de randare pe 5 cazuri reale pe care le-am implementat în producție.
1. Pagina de Termeni și Condiții (SSG Pur)
Aici n-are sens să ne complicăm. Pagina se modifică, în cel mai bun caz, o dată la câteva luni când se trezește departamentul legal.
- Strategia: Static Site Generation (implicit în Next.js dacă nu folosești funcții dinamice).
- De ce: Paginile se randează la build time. Zero request-uri către baza de date la runtime, viteză maximă pentru user și costuri zero pe hosting.
2. Blogul sau secțiunea de știri (ISR Clasic la interval de timp)
Am avut un proiect de content unde redactorii publicau cam 5-10 articole pe zi.
- Strategia: Incremental Static Regeneration cu un interval generos:
revalidate: 3600(o oră). - De ce: Dacă apare un typo într-un articol, nu moare nimeni dacă persistă maximum o oră în cache-ul vizitatorilor. Dacă e o urgență majoră, dăm un trigger manual la build sau folosim un webhook de revalidare. Economia la interogările SQL a fost de peste 70% față de vechea variantă pe WordPress.
3. Pagina de detalii produs în E-commerce (On-Demand Revalidation)
Aici e buba unde mulți dau greș. Dacă pui ISR la 60 de secunde, tot riști ca un user să cumpere un produs cu prețul vechi. Dacă folosești SSR (randare la fiecare request), site-ul se va mișca lent când ai spikes de trafic.
- Strategia: On-demand revalidation folosind tag-uri de cache (
revalidateTag). - Cum funcționează: Când un admin modifică prețul sau stocul în ERP/CMS, sistemul trimite un webhook securizat către Next.js care curăță cache-ul doar pentru produsul respectiv sau pentru categoria din care face parte. Userul primește mereu date proaspete, dar pagina se servește instant din cache-ul CDN-ului în 99% din timp.
4. Stocul în timp real sau campaniile de tip Flash Sale (Dynamic / Client-side)
Ce faci când stocul se epuizează în câteva secunde? Nicio formă de cache pe server nu te va salva aici.
- Strategia: Hibrid. Structura paginii (imagini, descriere) se servește din cache static, dar badge-ul de stoc și butonul de adaugă în coș fac un fetch direct din browser (folosind SWR sau React Query) direct dintr-un API rapid de Redis.
- Trade-off: Pagina se încarcă instant, dar ai un mic layout shift sau un skeleton loader până apare stocul exact. E un compromis necesar ca să nu vinzi produse pe care nu le ai în depozit.
5. Dashboard-ul de utilizator (No cache / Dynamic)
Date specifice fiecărui utilizator (istoric comenzi, setări profil, facturi).
- Strategia: Dynamic Rendering (echivalentul SSR-ului vechi) sau fetch-uri cu
cache: 'no-store'. - De ce: Datele sunt private și se schimbă des. Nu vrei sub nicio formă ca userul A să vadă din greșeală datele cache-uite ale userului B (am pățit-o la un audit de securitate unde un proxy configurat prost făcea exact asta).
Trade-off-ul sincer
On-demand revalidation e de departe cea mai elegantă soluție, dar vine cu o complexitate tehnică crescută. Trebuie să ai un CMS capabil să trimită webhook-uri corecte și trebuie să gestionezi scenariile în care apelul de revalidare eșuează. Dacă API-ul tău pică în timp ce Next.js încearcă să revalideze pagina în fundal, Next.js va continua să servească versiunea veche (stale), ceea ce e un fallback bun, dar tot trebuie să monitorizezi aceste erori.
Voi ce folosiți cel mai des în aplicațiile voastre? Vă asumați riscul datelor puțin învechite pentru o viteză mai bună sau preferați să randați totul dinamic?