const WP_API_URL = process.env.WORDPRESS_API_URL;
export async function getProducts(limit = 10) {
const query = `
query GetProducts($first: Int) {
products(first: $first) {
nodes {
id
name
slug
... on SimpleProduct {
price
}
}
}
}
`;
const res = await fetch(WP_API_URL, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ query, variables: { first: limit } }),
});
const { data } = await res.json();
return data?.products?.nodes || [];
}Să fim sinceri: headless WordPress cu Next.js sună extrem de bine pe hârtie. Zero încărcare greoaie, securitate maximă, scoruri de 100 în Lighthouse și un DX (Developer Experience) care te face să nu mai vrei să auzi în viața ta de fișiere PHP sau de buclele ciudate din WordPress.
Dar în producție, mai ales pe WooCommerce, povestea se schimbă radical. Am fost în tranșeele astea la un proiect cu peste 14.000 de produse active și 80k vizitatori unici pe lună. Am trecut de la o temă clasică la Next.js pe frontend și WPGraphQL pe backend. Am învățat câteva lecții dure pe banii și pe nervii mei.
Unde se rupe filmul: Mitul "e simplu"
Când faci headless pe un blog simplu, e floare la ureche. Când pui WooCommerce în ecuație, intri într-o gaură neagră. De ce? Pentru că pierzi instantaneu tot ecosistemul de plugin-uri care "pur și simplu funcționează".
Vrei cupoane dinamice? Trebuie să le programezi manual în React. Vrei o integrare cu Netopia sau Stripe care are widget nativ de WP? Baftă să rescrii toată logica de checkout în Next.js și să validezi sesiunile prin JWT-uri securizate. Am pierdut aproape trei săptămâni doar ca să refacem fluxul de checkout și să ne asigurăm că stocurile se actualizează corect în timp real, fără race conditions când doi useri cumpărau ultimul produs simultan.
Breakpoint-ul real: Când merită efortul?
Din experiența mea de până acum, nu te atinge de headless dacă magazinul nu trece de 50.000 de vizite lunare și nu are deja probleme serioase de performanță pe care nu le poți rezolva cu Redis, un CDN bun și puțin refactoring de baze de date.
Am avut cazul unui client care insista pentru headless la doar 5.000 de vizite pe lună. A fost o greșeală masivă din punct de vedere business. Costurile de mentenanță au explodat, iar clientul nu mai putea să-și schimbe un banner simplu în homepage fără să ne ceară nouă un deploy în Vercel.
Merită să faci trecerea DOAR dacă:
- Ai echipă dedicată: Ai nevoie de oameni care știu și React la nivel avansat, și cum să optimizeze interogările GraphQL în WP.
- Trafic mare și bugete mari de marketing: Acolo unde fiecare 100ms în plus la încărcare pe mobil înseamnă pierderi de mii de euro în campaniile de Ads.
- UI ultra-personalizat: Când design-ul cerut de UX-iști e atât de complex încât să-l faci în PHP sau Elementor devine un coșmar de spaghetti code.
Trade-off-ul sincer
Dacă rămâi pe PHP clasic, cu o temă custom (fără page buildere greoaie, scrisă curat cu Tailwind sau SASS) și un VPS bun de 20-30$ pe lună, duci lejer 100k vizitatori fără probleme de viteză. Am economisit cam 40% din timpul de dezvoltare la un proiect similar doar alegând să scriem o temă PHP hibridă, folosind Timber (Twig) în loc să ne complicăm cu Next.js.
Dacă totuși o iei pe drumul headless, iată cum arată o interogare simplă pentru produse prin WPGraphQL. Te scutește de REST API-ul clasic care e lent și trimite prea multe date inutile pe rețea.
Voi ce experiențe aveți? Ați încercat să duceți WooCommerce în headless și ați regretat când a trebuit să integrați procesatorul de plăți local, sau a meritat efortul pentru performanță?