add_action('rest_api_init', function () {
register_rest_field('producator', 'date_brand_curate', [
'get_callback' => function ($post_object) {
$post_id = $post_object['id'];
// Extragem doar ce ne interesează, fără overhead
return [
'website_oficial' => get_field('website_oficial', $post_id),
'logo_url' => get_field('logo_brand', $post_id)['sizes']['medium'] ?? '',
'tara_origine' => get_field('tara_origine', $post_id)
];
},
'schema' => null,
]);
});Salutare! Zilele trecute m-am lovit iar de clasica problemă în Headless WordPress: cum trimiți datele din Custom Post Types (CPT) și ACF către frontend fără să transformi API-ul într-un monstru care răspunde în două secunde. Am avut de implementat asta pentru un magazin WooCommerce cu vreo 14.000 de produse active, unde aveam un CPT separat numit „Producători” legat de produse prin relații ACF.
Implicit, dacă folosești WPGraphQL și bifezi „Show in GraphQL” în ACF, totul pare roz la început. Dai două click-uri, scrii query-ul și ai datele în Playground. Dar când începi să query-uiești relații complexe (de exemplu: Produs -> Brand CPT -> Locații service din ACF), WordPress începe să facă zeci de interogări SQL redundante în spate. La proiectul de care vă zic, primul build de Next.js dura aproape 25 de minute din cauza query-urilor blocate în WP. Am economisit 40% din timpul de build doar curățând aceste payload-uri.
Problema cu plugin-urile de tipul „out of the box”
Plugin-uri precum „ACF to REST API” sau extensiile automate de GraphQL sunt excelente pentru prototipuri rapide. În producție, însă, sunt o bombă cu ceas. Ele aruncă în API absolut toate metadatele: chei interne ACF care încep cu „_”, configurații de câmpuri, revizii și alte detalii de care Next.js sau Nuxt nu au nevoie ca să randeze o pagină.
Fiecare kilobyte în plus în payload-ul JSON înseamnă timp irosit la transfer și la parsare pe client. Soluția pe care am aplicat-o a fost eliminarea completă a expunerii automate și scrierea de handlere custom.
Soluția: REST API custom endpoint sau GraphQL selectiv?
Am avut de făcut un trade-off sincer. GraphQL e genial pentru flexibilitate pe frontend, dar pe WooCommerce masiv, overhead-ul adus de interogările dinamice te rupe la CPU dacă nu ai un server dedicat foarte bine optimizat. REST API-ul nativ, deși pare învechit, este mult mai ușor de pus în cache la nivel de Nginx sau Cloudflare.
Pentru datele conexe din CPT-uri am decis să merg pe REST API nativ, dar cu mapare manuală a câmpurilor. În loc să expun tot obiectul de post, înregistrez un câmp custom în REST care returnează doar strictul necesar.
Această metodă ne scapă de query-urile recursive și ne asigură că frontend-ul primește un JSON curat, plat, gata de randat. Dacă aveți relații de tip „Post Object” în ACF, puteți folosi exact aceeași logică pentru a returna doar ID-ul și URL-ul imaginii de preview, nu tot istoricul autorului și statusul comentariilor.
Până la urmă, headless-ul cu WordPress este o soluție excelentă doar dacă strunești baza de date cum trebuie. Dacă lași totul pe „default”, o să plângi în pumni la primul import masiv de produse.
Voi cum procedați când aveți de legat ACF de frontend-uri moderne? Vă chinuiți să optimizați WPGraphQL sau ați trecut și voi înapoi la endpoint-uri REST customizate și cache agresiv?