import { revalidateTag } from 'next/cache';
import { NextRequest, NextResponse } from 'next/server';
export async function POST(request: NextRequest) {
const secret = request.headers.get('x-wc-webhook-secret');
if (secret !== process.env.WC_WEBHOOK_SECRET) {
return NextResponse.json({ message: 'Unauthorized' }, { status: 401 });
}
const body = await request.json();
const productId = body.id;
if (productId) {
// Revalidăm cache-ul doar pentru produsul modificat
revalidateTag(`product-${productId}`);
revalidateTag('products-list');
return NextResponse.json({ revalidated: true, now: Date.now() });
}
return NextResponse.json({ message: 'Missing product ID' }, { status: 400 });
}Nu mai faceți storefront-uri în Next.js peste WooCommerce doar pentru că dă bine în CV. Am trecut anul trecut un magazin cu 25.000 de produse de pe o temă clasică PHP pe o arhitectură Headless cu Next.js App Router și WPGraphQL. TTFB-ul pe paginile de produs a scăzut de la 800ms la 90ms, dar costul de mentenanță și suport tehnic a crescut cu peste 200%.
Când ești prea mic pentru Headless WooCommerce
Dacă magazinul procesează sub 1.000 de comenzi pe lună și are un trafic sub 50.000 de vizitatori, Headless e pur și simplu o risipă de bani. Un WooCommerce clasic, pus pe un VPS decent de 20-30€/lună cu Redis Object Cache, PHP 8.3 și un CDN bun (Cloudflare sau Bunny), scade lejer sub 300ms la redare dacă nu încarci 50 de plugin-uri dubioase.
În versiunea monolit PHP, când clientul vrea un plugin nou de curierat, de opțiuni de plată sau de recenzii, îl instalezi și în 10 minute e funcțional. La Headless, fiecare plugin care atinge frontend-ul devine un task separat de dev: trebuie să expui datele în REST API sau GraphQL și să creezi componente React de la zero.
Breakpoint-ul real: Unde merită cu adevărat bătaia de cap?
Din experiența mea, trecerea la Next.js devine rentabilă financiar și tehnic doar când atingi una dintre condițiile astea:
- Spikes uriașe de trafic: Ai campanii de Black Friday unde intri cu 2.000+ utilizatori simultan pe site. Aici un frontend statificat (ISR) pe Vercel sau Cloudflare Pages nu crapă niciodată, în timp ce baza de date MySQL din spate rămâne relaxată.
- Arhitectură Omnichannel: Folosești același backend de WooCommerce pentru o aplicație mobilă nativă (React Native/Flutter), un sistem POS din magazinul fizic și site-ul web.
- UX ultraspecific: Ai un configurator 3D de produse sau un funnel de checkout extrem de personalizat pe care temele de PHP îl randau lent și greoi.
Marea problemă: Coșul de cumpărături și Session State
Cu paginile statice de produs e simplu: faci SSG sau ISR și site-ul e rachetă. Dar e-commerce-ul înseamnă dinamică. Când userul dă „Adaugă în coș”, intră în scenă WooCommerce Store API.
Am lovit o problemă urâtă de latență când endpoint-ul /wp-json/wc/store/v1/cart răspundea în 400ms din cauza interogărilor din MySQL. Practic, am câștigat viteză enormă pe navigare, dar am pierdut din rata de conversie pentru că adăugarea în coș părea lentă. Am fost nevoiți să implementăm un strat de stocare intermediar pe Redis direct în Node.js pentru starea coșului.
Cum gestionăm revalidarea stocurilor
Ca să nu faci fetch la fiecare vizită, folosești revalidateTag din Next.js combinat cu un webhook banal din WordPress. Când se modifică un stoc sau un preț în WooCommerce Admin, WP trimite un POST către Next.js și curăță cache-ul doar pentru produsul respectiv.
Concluzie
Până la o cifră de afaceri serioasă sau 100.000 de vizitatori lunari, o temă curată de PHP (cum e GeneratePress sau un Storefront modificat) cu un stack solid de caching bate oricând un Headless Next.js la capitolul ROI. N-are rost să complici infrastructura dacă nu te blochează performanța monolitului.
Voi ce soluții folosiți când WooCommerce începe să gâfâie: optimizați mai departe PHP-ul sau decuplați frontend-ul?