// app/api/revalidate/route.ts
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.WP_REVALIDATE_SECRET) {
return NextResponse.json({ message: 'Unauthorized' }, { status: 401 });
}
const body = await request.json();
const productId = body?.id;
if (productId) {
// Invalidăm cache-ul doar pentru produsul modificat în WooCommerce Admin
revalidateTag(`product-${productId}`);
return NextResponse.json({ revalidated: true, now: Date.now() });
}
return NextResponse.json({ message: 'Missing product ID' }, { status: 400 });
}Anul trecut am migrat un magazin WooCommerce cu peste 35.000 de produse de la o temă clasică de PHP la o arhitectură headless cu Next.js App Router și WPGraphQL. Proiectul a ieșit foarte bine pe partea de performanță, dar procesul ne-a mâncat câteva săptămâni bune din viață. Dacă te gândești să faci pasul ăsta, zic să citești mai jos înainte să le promiți clienților că headless rezolvă toate problemele.
Cifrele reale și ce am câștigat
Situația inițială era destul de clasică. Magazinul genera cam 300.000 de afișări pe lună, iar în perioadele de reduceri aveam spike-uri de 1.500 de utilizatori simultani. Serverul de PHP (o instanță măricică pe Hetzner cu Redis) intra în sufocare pe paginile de categorie și pe checkout din cauza numărului uriaș de query-uri SQL făcute de WooCommerce.
După migrarea frontend-ului pe Next.js și găzduirea lui pe Vercel, rezultatele au fost evidente:
- Time to First Byte (TTFB) a scăzut de la 1.2 secunde la sub 80ms globally.
- LCP-ul a coborât de la 2.8s la 450ms pe mobil.
- Factura de hosting pentru backend a scăzut cu aproape 60%, pentru că WordPress-ul primea acum request-uri doar din build-uri, revalidări de cache și apelurile de checkout.
Unde se rupe filmul: Trade-off-ul sincer
Sună excelent până când ajungi la logica de business și la utilizatorul final din admin. Un WordPress headless nu mai e un WordPress clasic.
În primul rând, ai omorât tot ecosistemul de plugin-uri vizuale. Clientul nu mai poate folosi Elementor, Divi sau Gutenberg așa cum era obișnuit. Pagina de produs devine o componentă de React. Dacă vor o secțiune nouă de testimonial-uri în layout, nu mai pot să tragă un widget cu drag-and-drop; trebuie să-ți ceară ție cod sau să creezi un sistem custom de blocuri în ACF Pro.
În al doilea rând, checkout-ul și gateway-urile de plată locale sunt un chin. Majoritatea plugin-urilor românești de plată sunt scrise presupunând că utilizatorul se află în sesiunea de PHP din WordPress. Când le decuplezi, ești nevoit să scrii endpoint-uri de REST/GraphQL personalizate sau să redirecționezi user-ul pe o pagină găzduită direct de PHP doar pentru checkout, ceea ce strică experiența de utilizare.
Breakpoint-ul de trafic: Când are sens și când e moft?
Din experiența mea, breakpoint-ul real nu e neapărat traficul, ci structura echipei și bugetul de mentenanță.
Dacă magazinul are sub 100.000 de vizite pe lună și o echipă mică fără un developer React dedicat, nu merită sub nicio formă. O temă PHP bine optimizată (cum e GeneratePress), cu un PHP 8.2+, Redis object cache și un CDN serios în față (Cloudflare APO) va rula impecabil și va costa de zece ori mai puțin ca dezvoltare.
Momentul de trecere la Headless apare când:
- Ai peste 200.000 - 300.000 de vizite/lună și baze de date imense unde căutările și filtrele PHP paralizează serverul.
- Ai deja aplicații mobile unde refolosești API-ul de GraphQL/REST.
- Echipa de marketing înțelege că nu va mai avea libertate totală de drag-and-drop fără sprijin de dev.
A mai încercat cineva de aici combinația WooCommerce + Next.js pe producție? Cum ați rezolvat integrarea cu procesoarele de plată locale fără să trimiteți userul pe PHP?