export async function getProducts(limit = 12) {
const query = `
query GetProducts($limit: Int) {
products(first: $limit) {
nodes {
id
name
slug
... on SimpleProduct {
price
}
}
}
}
`;
const res = await fetch(process.env.WORDPRESS_GRAPHQL_ENDPOINT!, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
next: { revalidate: 3600 }, // Cache pe server timp de o oră
body: JSON.stringify({ query, variables: { limit } }),
});
const { data } = await res.json();
return data?.products?.nodes || [];
}Am văzut prea multe startup-uri care sar direct la Next.js cu WordPress pe post de backend doar pentru că e la modă. Dacă ai un magazin WooCommerce, decizia asta îți poate dubla timpul de development sau, dimpotrivă, îți poate salva bugetul de hosting. Hai să vedem unde e pragul real unde merită să faci trecerea și când e mai bine să rămâi pe clasicul PHP.
De ce ne bate capul headless-ul pe WooCommerce
Am avut acum doi ani un proiect, un shop cu vreo 15.000 de produse și în jur de 80.000 de vizitatori pe lună. Clientul voia neapărat "să zboare site-ul" și a insistat pe Next.js. Am zis "ok, facem cu GraphQL și WPGraphQL". Spun sincer, ne-am asumat un risc uriaș.
Toate bune până am ajuns la checkout. Aici începe coșmarul pe headless. Plugin-ul de curierat (Sameday) și cel de procesare plăți (Netopia) aveau nevoie de hook-urile clasice de PHP din WooCommerce ca să calculeze rutele și să genereze token-urile de plată. Am pierdut trei săptămâni doar rescriind integrări API în Next.js pe care în PHP le rezolvam cu trei click-uri.
Trade-off-ul e clar: câștigi 1-2 secunde la încărcare și o experiență de navigare instantanee pentru user, dar pierzi tot ecosistemul de plugin-uri gata făcute. Fiecare funcționalitate nouă (un pixel de tracking mai ciudat, un sistem de loialitate) înseamnă că devii tu integratorul de API-uri.
Breakpoint-ul real de trafic și buget
Din experiența mea de până acum, dacă magazinul are sub 50.000 de vizite unice pe lună, headless este o risipă uriașă de resurse. Un VPS de 15 euro cu OpenLiteSpeed, Redis, un plugin bun de cache (cum e LSCache) și o temă curată în PHP (sau un builder modern ca Bricks) va scoate sub 1 secundă timp de încărcare pentru paginile cache-uite. Nu ai nevoie de Next.js pentru asta.
Pragul unde Next.js începe să aibă sens este pe la 150.000+ vizite pe lună și când ai bugete de marketing de mii de euro. Acolo, o îmbunătățire de 0.5 secunde în conversion rate, obținută prin tranziții instatanee între pagini (datorită pre-fetching-ului din Next.js), chiar își scoate banii investiți în programatori React.
De asemenea, dacă ai nevoie de o arhitectură multi-store (aceeași bază de date WooCommerce alimentează o aplicație mobilă și trei site-uri de nișă diferite), headless devine brusc cea mai curată opțiune.
Cum arată interogarea de date?
Dacă totuși decizi să o faci, nu folosi REST API-ul nativ din WP pentru interogări mari; e extrem de lent pentru că încarcă tot bootstrap-ul de WordPress la fiecare request. Mergi pe GraphQL. Uite o funcție simplă de fetch pentru produse pe care o folosesc ca să evit overhead-ul, folosind Next.js App Router cu ISR (Incremental Static Regeneration).