type GraphQLResponse<T> = { data: T; errors?: Array<{ message: string }> };
export async function fetchWooCommerceProduct<T>(slug: string): Promise<T> {
const res = await fetch(process.env.WORDPRESS_GRAPHQL_ENDPOINT!,
method: 'POST',
headers: { 'Content-Type': 'application/json' },
next: {
revalidate: 3600,
tags: [`product-${slug}`]
},
body: JSON.stringify({
query: `
query GetProduct($id: ID!) {
product(id: $id, idType: SLUG) {
id
name
slug
... on SimpleProduct { price rawPrice }
}
}
`,
variables: { id: slug }
})
});
const json: GraphQLResponse<T> = await res.json();
if (json.errors) throw new Error(json.errors[0].message);
return json.data;
}Am migrat în ultimii trei ani vreo patru magazine WooCommerce pe Next.js headless și m-am lovit de toate problemele posibile. Dacă te bate gândul să faci mutarea asta, scriu asta ca să nu repeți greșelile mele și să înțelegi exact breakpoint-ul financiar și de trafic. Spoiler alert: în 80% din cazuri, o temă PHP bine optimizată e tot ce ai nevoie.
Unde se rupe filmul pe monolith-ul clasic
Când ai un WooCommerce clasic cu 20.000 de produse și peste 100k de vizitatori pe lună, baze de date MySQL încep să gâfâie grav. Am avut un caz pe o nișă de fashion unde admin-ajax.php devenise un coșmar la fiecare campanie de Black Friday. TTFB-ul sărise la 2.2 secunde, iar serverul dedicat de 150€/lună cădea la orice apel de cart fragments sau filtrare complexă.
Atunci am decis să trecem pe Next.js cu App Router și WPGraphQL. Rezultatul imediat? TTFB-ul a scăzut la sub 150ms pe paginile de produs prin ISR (Incremental Static Regeneration), iar experiența de navigare s-a simțit instantă. Dar de aici au început problemele reale de arhitectură pe care nimeni nu ți le spune când laudă stack-ul ăsta pe YouTube.
Costul ascuns: plugin-urile mor subit
În secunda în care decuplezi frontend-ul, 90% din plugin-urile tale preferate de WooCommerce devin inutile pe partea vizuală. Rank Math sau Yoast nu mai injectează meta-urile direct în HTML. Plugin-urile de checkout, curierat, gateway-uri de plată locale (PayU, Netopia) sau generatoare de AWB-uri nu au endpoint-uri de GraphQL gata făcute.
Trebuie să scrii wrapper-e custom în PHP ca să expui datele în GraphQL, apoi să reconstruiești componente de React pentru fiecare flux în parte. Preview-ul de pagini din WordPress devine un calvar de configurat cu webhook-uri și tokens de autentificare. În loc să livrezi un proiect în 3 săptămâni, te trezești că lucrezi 3 luni doar la paritate de funcționalități.
Breakpoint-ul real: când chiar merită?
Din experiența mea de până acum, ecuația se rezumă la buget și capabilități de echipa.
Rămâi pe tema PHP (Monolith + Redis + Cloudflare) dacă:
- Ai sub 50k - 80k vizitatori unici pe lună.
- Bugetul inițial de dezvoltare e sub 10.000€.
- Echipa de marketing depinde direct de Elementor, Divi sau block-uri Gutenberg complexe.
Merită Headless cu Next.js doar dacă:
- Depășești 150k vizitatori/lună și ai spikes mari de trafic pe care PHP nu le mai poate duce fără să scalezi agresiv infrastructura.
- Ai peste 15.000 de SKU-uri și filtre complexe pe care le împingi în ElasticSearch sau Meilisearch.
- Ai nevoie de aceleași date în aplicație mobilă nativă și pe web.
- Ai un buget de mentenanță dedicat (un dev React + un dev PHP) și o infrastructură solidă pe Vercel/AWS combinată cu un WP Engine pe backend.
Cum arată un fetch de produs cu revalidare
În Next.js App Router, șmecheria e să folosești revalidarea la nivel de tag sau timp ca să nu omori instanța de WordPress cu interogări GraphQL la fiecare request de la utilizatori.
Decizia de a trece pe headless nu e despre performanță brută, ci despre un trade-off clar între viteză la nivel de frontend și complexitatea mentenanței pe backend. Voi ați încercat să decuplați WooCommerce până acum sau ați rămas pe abordarea clasică cu Redis și cache la nivel de edge?