add_filter('rest_prepare_manuale', function($response, $post, $request) {
$data = $response->get_data();
// Eliminăm balastul nativ din WordPress care încarcă payload-ul
$chei_inutile = ['ping_status', 'comment_status', 'template', 'format', 'author'];
foreach ($chei_inutile as $cheie) {
unset($data[$cheie]);
}
// Injectăm doar ACF-urile specifice de care avem nevoie în frontend
$data['pdf_ghid'] = get_field('pdf_ghid', $post->ID);
$data['produs_asociat_id'] = get_field('produs_asociat_id', $post->ID);
$response->set_data($data);
return $response;
}, 10, 3);Am lucrat recent la un magazin headless unde a trebuit să legăm WooCommerce de niște Custom Post Types (CPT) pentru ghiduri tehnice și manuale de utilizare, toate populate prin ACF (Advanced Custom Fields). Dacă lași WordPress-ul să își facă de cap implicit, API-ul îți scuipă megabiți de JSON inutil care îți omoară performanța pe frontend. La un catalog cu vreo 4.000 de produse, chestia asta devine rapid critică.
Hai să vedem cum am rezolvat problema payload-ului obez și de ce am decis să facem trecerea de la REST API la GraphQL la jumătatea proiectului.
Coșmarul REST API și câmpurile inutile
Am început clasic, cu register_post_type și show_in_rest => true. Pentru ACF-uri, am bifat „Show in REST API” direct din interfață. Totul părea simplu până când am deschis Postman.
Când făceam fetch pe un singur manual de utilizare, REST API-ul îmi întorcea un JSON imens. Link-uri de rețele de la Jetpack, statusuri de ping, revizii, taxonomii de care n-aveam nevoie în Next.js și tot felul de metadate native. În total, vreo 15KB per postare pentru niște date din care eu foloseam doar titlul și un URL de PDF. La liste mari, chestia asta îți triplează timpul de parsare pe client.
Soluția rapidă pe REST a fost să interceptăm răspunsul API-ului prin filtrul rest_prepare_{post_type} din WordPress și să curățăm manual array-ul de date înainte de a fi trimis spre frontend. Am scăzut dimensiunea payload-ului cu aproape 60% doar eliminând proprietățile native inutile.
De ce GraphQL a salvat situația (și trade-off-ul sincer)
Deși filtrarea din PHP a funcționat pentru pagini simple, problemele au apărut când am început să legăm manualele de produsele din WooCommerce (relații de tip many-to-many). Să faci query-uri de REST în Next.js, să iei ID-ul produsului, apoi să faci alt request în API-ul WooCommerce ca să iei detaliile produsului... e rețeta perfectă pentru un waterfall de request-uri lent.
Am instalat WPGraphQL și extensia WPGraphQL for ACF. Brusc, totul s-a transformat în query-uri curate unde frontend-ul cere exact ce are nevoie:
query GetManual {
manuale(first: 10) {
nodes {
title
acfManuale {
pdfGhid {
mediaItemUrl
}
produsAsociat {
... on Product {
id
name
price
}
}
}
}
}
}
Dar haideți să fim sinceri cu trade-off-ul: WPGraphQL e genial pentru flexibilitate, dar adaugă un overhead masiv de memorie pe server. Dacă rulezi pe un hosting shared ieftin, WPGraphQL o să îți îngenuncheze baza de date la query-uri mai complexe. Pe un VPS de 20 de euro, a trebuit să configurăm Redis la sânge și pluginul WPGraphQL Cache ca să coborâm timpul de răspuns sub 120ms.
Cum configurezi corect CPT-ul în cod pentru GraphQL
Ca să nu te bazezi doar pe pluginuri de interfață, cel mai curat mod este să înregistrezi CPT-ul direct din cod, specificând argumentele pentru GraphQL.
Trebuie să adaugi trei chei esențiale în array-ul de configurare: show_in_graphql => true, graphql_single_name => 'manual' și graphql_plural_name => 'manuale'. Astfel, schema se generează automat și corect, fără să poluezi namespace-ul global.
Concluzia mea e simplă: dacă ai un site de prezentare cu relații simple între date, rămâi pe REST API și folosește filtrul de curățare din PHP pentru a economisi lățime de bandă. Dacă lucrezi cu WooCommerce headless și ai nevoie de relații complexe între produse și CPT-uri, GraphQL e singura cale logică, dar nu ignora caching-ul la nivel de server.
La proiectele voastre headless cum ați procedat? Ați rămas pe REST sau ați făcut pasul spre GraphQL?