import { NextRequest, NextResponse } from 'next/server';
import { revalidatePath } from 'next/cache';
export async function POST(req: NextRequest) {
try {
const body = await req.json();
const { id, slug } = body; // Datele trimise de webhook-ul WooCommerce
if (!slug) {
return NextResponse.json({ message: 'Missing product slug' }, { status: 400 });
}
// Revalidăm pagina produsului specific și homepage-ul
revalidatePath(`/produse/${slug}`);
revalidatePath('/');
return NextResponse.json({ revalidated: true, now: Date.now() });
} catch (err) {
return NextResponse.json({ message: 'Error revalidating' }, { status: 500 });
}
}Am văzut prea multe magazine online care sar direct la Next.js cu WordPress headless doar pentru că e la modă, fără să facă un calcul real de ROI. Scalabilitatea sună bine pe hârtie, dar în producție te lovești de o complexitate tehnică și de costuri de mentenanță care nu se justifică mereu. Hai să vedem unde e pragul de rentabilitate și când e mai inteligent să rămâi pe clasicul PHP.
Mitul vitezei și realitatea din WooCommerce
Anul trecut am lucrat la un proiect cu peste 15.000 de produse active în WooCommerce. Clientul voia neapărat headless pentru că "așa e rapid". Realitatea? Un server VPS bine configurat, cu Redis, OPcache și Cloudflare în față, scotea deja sub 1.2 secunde timp de încărcare pe tema clasică de PHP.
Când treci pe headless, scapi de încărcarea bazei de date pentru randarea paginilor, dar muți complexitatea în altă parte. Brusc, ai nevoie de un middleware care să traducă query-urile de GraphQL (folosind WPGraphQL) sau REST API. Dacă ai 20 de pluginuri de marketing, cupoane complexe sau sisteme de transport, va trebui să rescrii manual toată logica lor de frontend în React. Am pierdut peste 80 de ore doar refăcând integrarea cu un plugin de curierat local care nu avea API compatibil cu React.
Breakpoint-ul real de trafic și buget
Din experiența mea, pragul critic unde merită să faci trecerea este la peste 150.000 de vizitatori unici pe lună sau când ai campanii agresive de tip Black Friday cu mii de utilizatori simultan în coș.
La volumul ăsta, baza de date de la WordPress începe să gâfâie din cauza conexiunilor simultane pentru paginile statice. Next.js rezolvă asta excelent prin SSG (Static Site Generation) și ISR (Incremental Static Regeneration). Serverul de WordPress nu mai vede deloc traficul de vizitare, ci doar request-urile de checkout și update-urile de stoc.
Trade-off-ul este însă masiv pentru echipa de marketing. Își pierd complet libertatea din Gutenberg sau Elementor. Orice landing page nou sau schimbare de banner necesită un deploy sau o structură complexă de blocuri dinamice mapate în Next.js. Noi am economisit cam 35% la costurile de hosting după migrare, dar am dublat bugetul de mentenanță lunară pentru că acum avem nevoie de developeri de React, nu doar de oameni de WordPress.
Cum rezolvi sincronizarea stocurilor (ISR)
Cea mai mare problemă la WooCommerce headless este că stocurile se schimbă des, iar paginile statice din Next.js rămân în urmă. Soluția curată este să folosești On-Demand Revalidation. Când un produs se vinde sau este actualizat în WP, trimiți un webhook către Next.js ca să curețe cache-ul doar pentru acea pagină.
Uite un exemplu simplu de API Route în Next.js (App Router) care ascultă de webhook-ul din WooCommerce și revalidează produsul instant.
Next.js cu WordPress headless este o soluție excelentă, dar numai dacă ai trecut de faza de validare a business-ului și ai bugete de dezvoltare de peste 5.000 de euro pe an doar pentru mentenanță. Dacă ești sub pragul ăsta, o temă PHP curată, optimizată corect, îți va aduce aceleași vânzări, cu 10% din bătăile de cap.
Voi ați încercat soluția asta? V-ați lovit de probleme la sincronizarea coșului de cumpărături?