import type { NextApiRequest, NextApiResponse } from 'next'
export default async function handler(
req: NextApiRequest,
res: NextApiResponse
) {
// Webhook simplu apelat de WP la update de produs pentru revalidare ISR
if (req.headers.authorization !== `Bearer ${process.env.REVALIDATION_TOKEN}`) {
return res.status(401).json({ message: 'Invalid token' })
}
try {
const { slug } = req.body
await res.revalidate(`/produs/${slug}`)
return res.json({ revalidated: true })
} catch (err) {
return res.status(500).send('Error revalidating')
}
}Am văzut în ultima vreme o febră nebună cu headless WordPress combinat cu Next.js, mai ales pe partea de WooCommerce. Toată lumea vrea performanță de tip SPA, dar puțini calculează costurile de infrastructură și mentenanță înainte să arunce la gunoi vechiul cod PHP. Am trecut prin ambele tabere și am simțit pe pielea mea unde se rupe filmul.
Mitul vitezei și realitatea din producție
Toată lumea promite că site-ul va zbura dacă treci pe headless. Da, un site Next.js găzduit pe Vercel, cu pagini statice generate prin ISR (Incremental Static Regeneration), se încarcă în sub o secundă. Dar asta e valabil mai mult pentru site-uri de prezentare sau bloguri unde conținutul se schimbă rar.
La un magazin online cu peste 8.000 de produse și actualizări constante de stocuri, lucrurile devin extrem de complicate. Am avut un proiect unde clientul schimba prețurile din ERP de trei ori pe zi. La fiecare modificare, trebuia să facem revalidare de pagini. Ghici ce? API-ul din WordPress (foloseam WPGraphQL) s-a transformat rapid într-un bottleneck. Baza de date a început să gâfâie sub asaltul request-urilor de build din Next.js. Am rezolvat-o doar după ce am pus un Redis masiv în față, dar asta a anulat toată promisiunea de „simplu și ieftin”.
Breakpoint-ul real: Când merită Next.js?
Din experiența mea, pragul unde Next.js începe să aibă sens este la peste 50.000 de vizitatori unici pe lună, dar doar dacă ai o structură de catalog relativ stabilă și un buget serios de dev.
Dacă ai sub 10.000 de vizite și vinzi 50 de produse, să faci headless e masochism curat. Plătești hosting dublu (WP pentru admin + Vercel/Netlify pentru frontend), pierzi preview-ul nativ din WordPress (care se configurează greu pe headless) și pierzi compatibilitatea cu 90% din plugin-urile de marketing, SEO și checkout.
În schimb, dacă ai trafic mare și vrei o aplicație web mobilă extrem de rapidă, unde UX-ul direct influențează rata de conversie, Next.js te ajută să economisești la hosting-ul de producție. Am economisit cam 30% la costurile de server mutând tot consumul de resurse de pe un VPS greoi pe CDN-ul Vercel, lăsând WordPress-ul doar ca o bază de date chioară în spate, protejată de public.
Trade-off-ul pe WooCommerce
Să fim sinceri: WooCommerce nu a fost gândit pentru headless. Cart-ul, sesiunile de checkout, cupoanele și gateway-urile de plată funcționează nativ prin sesiuni PHP. În momentul în care separi frontend-ul, trebuie să muți tot acest state-management în React. Spui adio plugin-urilor de tip "One Click Checkout" luate de pe internet. Va trebui să scrii tu integrarea API pentru fiecare metodă de plată. Asta înseamnă sute de ore de development în plus și un buget de mentenanță pe măsură.
Dacă rămâi pe o temă PHP clasică, bine optimizată (cu un stack modern gen Sage de la Roots, Tailwind și puțin Alpine.js), poți obține scoruri de peste 90 în Lighthouse fără să te legi la cap cu arhitecturi complexe.
Voi cum ați rezolvat problema sincronizării stocurilor în timp real pe headless? Ați rămas pe WPGraphQL sau ați făcut rute custom de REST?