add_action('graphql_register_types', function() {
register_graphql_field('Lookbook', 'associatedProductIds', [
'type' => ['list_of' => 'Integer'],
'description' => __('IDs of WooCommerce products featured in this lookbook', 'textdomain'),
'resolve' => function($post) {
$products = get_field('featured_products', $post->databaseId);
return !empty($products) ? array_map('intval', $products) : [];
}
]);
});Salutare. Am lucrat recent la migrarea unui magazin WooCommerce destul de mare (peste 14.000 de produse) către un frontend headless în Next.js și m-am lovit din nou de clasica problemă: cum expui curat campaniile și lookbook-urile create cu Custom Post Types (CPT) și ACF, fără să explodeze API-ul. Dacă folosești WordPress pe post de CMS decuplat, probabil știi deja cât de mizerabil poate deveni JSON-ul returnat implicit.
Coșmarul REST-ului implicit
La începutul proiectului, echipa de frontend folosea REST API-ul nativ din WP. Am pățit să avem un timp de răspuns de peste 1.2 secunde pe un endpoint simplu de lookbook. De ce? Pentru că WP trimitea absolut tot: conținut randat, taguri HTML inutile, rute de comentarii și toate meta-datele posibile. La un volum de 8k de vizitatori pe zi, serverul de backend gâfâia serios.
Trecerea la WPGraphQL a fost salvatoare, dar vine cu un compromis. Dacă folosești plugin-ul WPGraphQL for ACF, acesta îți expune automat toate câmpurile, însă schema devine rapid gigantică și greu de întreținut. În plus, interogările complexe pot duce la memory leaks pe serverele de hosting shared sau VPS-uri slab configurate.
Soluția: Maparea manuală a câmpurilor în GraphQL
În loc să las plugin-ul să expună automat tot ce găsește în baza de date, am preferat să scriu resolvere custom pentru WPGraphQL. Da, scrii mai mult cod PHP, dar controlezi la milimetru ce ajunge în frontend.
De exemplu, pentru un CPT numit lookbook unde administratorul magazinului alege câteva produse recomandate printr-un câmp de tip Relație (ACF), nu am nevoie de tot obiectul de produs în primă fază. Frontend-ul are nevoie doar de ID-urile acelor produse pentru a face ulterior un query optimizat în cache-ul Apollo.
Trade-off-ul sincer: Timp de dezvoltare vs. Performanță
Abordarea asta manuală are un dezavantaj clar: când marketingul cere un câmp nou în ACF, trebuie să intri în codul de PHP și să-l înregistrezi în schemă. Nu mai merge faza cu "am adăugat câmpul în admin și apare instant în API".
Totuși, câștigul de performanță e uriaș. Pe proiectul nostru, payload-ul JSON pentru o pagină de campanie a scăzut de la 120KB la doar 8KB, iar timpul de query pe baza de date s-a redus cu aproximativ 35%. Merită efortul? Pentru un magazin de prezentare mic, probabil că nu. Pentru un WooCommerce cu trafic mare unde fiecare sută de milisecunde contează la rata de conversie, cu siguranță da.
Cum gestionați voi datele astea în proiecte headless? Mergeți pe varianta rapidă cu plugin-uri automate sau preferați să scrieți resolvere custom pentru siguranță?