add_action('rest_api_init', function () {
register_rest_field('produs_custom', 'specificatii_scurte', [
'get_callback' => function ($post_object) {
$post_id = $post_object['id'];
return [
'material' => get_field('material_produs', $post_id),
'greutate' => (float) get_field('greutate_produs', $post_id),
'disponibil' => (bool) get_field('in_stoc', $post_id)
];
},
'schema' => null,
]);
});Salutare. Am lucrat recent la un catalog de produse custom, un hibrid de WooCommerce cu destul de mult content customizat, unde aveam în jur de 12.000 de entry-uri active. Clientul voia neapărat Next.js pe frontend. Toate bune și frumoase, am făcut CPT-urile, am definit ACF-urile pentru specificațiile tehnice complexe, dar când am deschis prima dată endpoint-ul de REST... m-am speriat. Aveam un payload de aproape 4MB pentru o listă simplă de 20 de iteme.
WordPress are prostul obicei să scuipe absolut tot în REST API dacă bifezi "Show in REST". Primești zeci de câmpuri de care nu ai nevoie pe frontend: statusuri de ping, formate, taxonomii interne și tot felul de metadate de care nu se atinge nimeni. Dacă mai pui și ACF-ul în ecuație, JSON-ul devine rapid un labirint imposibil de parcurs.
Hai să vedem cum rezolvăm problema asta curat, fie că mergi pe REST clasic, fie pe GraphQL.
Varianta REST: register_rest_field este sfânt
Cea mai mare greșeală pe care o văd în producție este activarea opțiunii globale "Show in REST API" direct din setările ACF. Da, este comod. Însă asta îți va trânti un obiect uriaș numit acf în răspunsul API, plin de zgomot.
Eu prefer să dezactivez acea opțiune globală și să-mi înregistrez manual doar câmpurile de care am cu adevărat nevoie pe frontend. Folosesc register_rest_field în tema sau în plugin-ul de funcționalități. În felul ăsta, controlez exact structura cheilor. Nu mai am acele structuri imbricate de tipul acf.nume_camp, ci pot expune datele direct la rădăcina obiectului, curate și gata formatate.
Am salvat în jur de 60% din dimensiunea payload-ului pe proiectul de care vă spuneam. În loc de 4MB pe request-ul de listare, am coborât la vreo 180KB, ceea ce a schimbat complet performanța pe Next.js la build time.
Varianta GraphQL: WPGraphQL și schema strictă
Dacă folosești WPGraphQL, lucrurile stau mult mai bine la nivel de payload pentru că ceri doar ce ai nevoie. Totuși, ai altă bătaie de cap: schema. Ca să expui ACF în GraphQL, ai nevoie de extensia WPGraphQL for ACF.
Sistemul funcționează brici pentru câmpuri simple de tip text sau număr. Însă, când dai de relații complexe sau de câmpuri de tip Flexible Content, schema generată automat devine un monstru greu de gestionat pe frontend.
Trade-off-ul sincer: REST vs GraphQL în WordPress
Ambele tabere au bubele lor. REST este super ușor de debuguit direct în browser și nu crapă dacă adaugi un câmp nou greșit pe frontend, dar consumă bandă inutilă dacă nu ești extrem de disciplinat cu filtrele în PHP.
GraphQL îți dă query-uri curate pe client, dar adaugă o complexitate uriașă în PHP și consumă mult mai multe resurse de procesare pe server pentru parsarea schemei. Dacă rulezi pe un server shared ieftin, WPGraphQL o să-ți pună baza de date în genunchi la doar 100 de useri concurenți.
Pentru site-uri medii, REST API curățat prin hooks este de departe cea mai stabilă soluție. Nu adaugi dependențe grele, pui un Cloudflare în față și ai scăpat de griji.
Cum procedați în proiectele voastre de headless? Preferați să curățați endpoint-urile default sau scrieți controllere complet custom de la zero?