// app/api/revalidate/route.ts - Handler pentru webhook din WP la update de produs
import { revalidateTag } from 'next/cache';
import { NextResponse } from 'next/server';
export async function POST(request: Request) {
const secret = request.headers.get('x-wc-webhook-secret');
if (secret !== process.env.WC_WEBHOOK_SECRET) {
return NextResponse.json({ message: 'Secret invalid' }, { status: 401 });
}
const body = await request.json();
const productId = body?.id;
if (productId) {
// Curățăm cache-ul ISR strict pentru produsul modificat
revalidateTag(`product-${productId}`);
return NextResponse.json({ revalidated: true, now: Date.now() });
}
return NextResponse.json({ message: 'ID produs lipsă' }, { status: 400 });
}Am văzut prea mulți clienți care cer "Headless" doar pentru că sună bine în ședințele de management. Realitatea e că mutarea unui magazin WooCommerce pe Next.js este o sabie cu două tăișuri. În postarea asta vă zic din experiență unde apare pragul real de trafic și când e o greșeală enormă de arhitectură.
Mitul vitezei și coșmarul plugin-urilor WooCommerce
Când ai un shop clasic pe PHP încărcat cu 40 de plugin-uri active, TTFB-ul e jale. Am avut acum doi ani un proiect cu peste 20k de produse pe un server dedicat care abia mai respira în vinerea neagră. Tentația a fost mare: hai să facem Headless. Am mers pe Next.js, WPGraphQL și WooCommerce GraphQL.
Front-end-ul a devenit rachetă (100 pe Lighthouse fără efort), dar am dat repede de zid. În momentul în care ieși din ecosistemul PHP nativ, pierzi compatibilitatea directă cu 90% din plugin-urile din marcat. Vrei un checkout customizat, integrare cu un procesator local de plăți sau un plugin românesc de generat AWB-uri? Ghici ce: trebuie să scrii tu puntea prin REST API sau Webhooks.
Breakpoint-ul de trafic: Când devine matematică pură
Unde e pragul real? Din testele și proiectele mele, dacă ești sub 40.000 - 50.000 de vizitatori unici pe lună, arhitectura headless e pură risipă de buget. Întreținerea unei aplicații Node/Next.js găzduite pe Vercel plus backend-ul de WordPress te costă dublu ca ore de dev.
În schimb, la peste 150.000 de vizite lunare și un catalog mare care se schimbă des, arhitectura hibridă cu Next.js ISR (Incremental Static Regeneration) își scoate banii. Am salvat cam 35% la build time și am redus masiv încărcarea pe MySQL, pentru că WordPress livra doar JSON curat prin GraphQL, fără să mai randeze template-uri PHP pentru fiecare vizitator.
Ce alegi în practică?
Dacă ai un proiect cu echipă internă de frontend și buget de mentenanță continuă, mergi pe Next.js. Ai control total pe UX, micro-interacțiuni fără latență și poți trânti un CDN agresiv în față.
Dacă e vorba de un shop unde clientul vrea să instaleze singur un plugin de pop-up la 11 noaptea, rămâi pe o temă PHP optimizată (sau un starter curat gen Sage/Timber). Trântești un Redis Caching bun, configurezi Cloudflare și scapi de tichete de suport de tipul "de ce nu se mai vede bannerul".
Checkout-ul și stocurile rămân oricum greu de gestionat în headless dacă ai fluxuri complexe. Voi ce experiențe aveți cu WPGraphQL pe magazine mari? Ați rămas pe Headless sau v-ați întors la monolitul PHP?