import { GraphQLClient, gql } from 'graphql-request';
const wpClient = new GraphQLClient(process.env.WORDPRESS_GRAPHQL_ENDPOINT!);
const GET_PRODUCTS = gql`
query GetProducts($first: Int!) {
products(first: $first) {
nodes {
id
name
slug
... on SimpleProduct {
price
}
}
}
}
`;
export async function getCatalogProducts(limit = 12) {
const data = await wpClient.request(GET_PRODUCTS, { first: limit }, {
next: { revalidate: 3600, tags: ['woocommerce-products'] }
});
return data.products.nodes;
}Să fim sinceri: e plin LinkedIn-ul de dev-i care spun că PHP e mort și că dacă nu faci WooCommerce pe Next.js sau Remix ești rămas în trecut. Am mușcat și eu momeala asta acum doi ani la un client din e-commerce cu peste 12.000 de SKUs și un trafic de ~150k vizitatori pe lună.
Rezultatul? Un site rachetă, dar și vreo 200 de ore de muncă în plus pe lucruri care pe o temă clasică de WordPress durau zece minute. Dacă te bate gândul să propui headless la următorul proiect de Woo, hai să-ți spun exact unde e pragul real unde merită din punct de vedere financiar și tehnic.
Unde câștigi masiv cu Next.js (ISR)
La proiectul de care vă ziceam, aveam o problemă masivă de TTFB la campaniile mari. Baza de date din WordPress pica în cap când intrau 2.000 de useri simultan și făceau filtrări complexe pe atribute (mărimi, culori, branduri). Query-urile din WooCommerce sunt notorii pentru cât de neoptimizate sunt când ai multe variații.
Prin Next.js cu App Router și Incremental Static Regeneration (ISR), am mutat 95% din încărcare în CDN. TTFB-ul a scăzut de la 850ms la 45ms. Paginile de produs se încărcau instant, iar scorul de Mobile Performance în PageSpeed Insights a sărit de la 42 la 96. În plus, când a venit următorul Black Friday, serverul de WordPress abia dacă a simțit traficul, pentru că primea doar query-uri GraphQL la revalidare și API calls pe cart/checkout.
Când e o greșeală catastrofală să alegi Headless
Cât timp totul e static, ești în rai. Când ajungi la funcționalități specifice de e-commerce, începe coșmarul.
Trebuie să înțelegi un lucru simplu: în momentul în care ai scos tema de PHP, ai pierdut 90% din ecosistemul de plugin-uri WooCommerce. Vrei un plugin de Wishlist? Nu mai e suficient să dai „Activate”. Trebuie să scrii tu integrarea cu REST API sau GraphQL în frontend. Vrei filtre complexe? Trebuie să-ți construiești propriul index (eventual cu Meilisearch sau Algolia) pentru că wp-json e încet rău la căutări dinamice.
Checkout-ul e altă durere de cap. Dacă folosești Stripe sau Netopia, gateway-urile au SDK-uri, dar iframe-urile și fluxurile de 3D Secure pe un frontend decuplat necesită atenție sporită la securitate și stări de gestiune a coșului.
Breakpoint-ul real: Când merită trecerea?
După trei proiecte headless livrate, am tras o linie clară:
- Sub 40k-50k vizitatori/lună: NU merită. Rămâi pe o temă curată de PHP (cum ar fi Sage/Roots sau GeneratePress), pune un Redis Object Cache, folosește LiteSpeed Server și optimizează baza de date. Faci același lucru cu 10% din buget.
- Peste 100k unici/lună și vârfuri mari de trafic: Aici headless devine aur curat. Când costul de infrastructură pentru un cluster de MySQL devine uriaș, statizarea catalogului prin Next.js îți salvează bugetul de servere.
- Echipă de dev-i dedicată: Dacă clientul n-are buget de mentenanță pentru frontend de React separat de backend-ul de WP, nu-i vinde headless. Un update de WooCommerce îi va sparge API-ul mai devreme sau mai târziu.
Cum facem fetch curat la produse cu GraphQL
Ka să nu reinventezi roata, folosești wp-graphql și wp-graphql-woocommerce. Mai jos e modelul simplu de fetch pe RSC (React Server Components) cu revalidare la timp.
Voi ce experiențe aveți cu WP Headless? Ați regretat vreo trecere la Next.js pe magazine online sau a meritat fiecare linie de cod?