add_filter('rest_prepare_brand', 'clean_brand_rest_response', 10, 3);
function clean_brand_rest_response($response, $post, $request) {
$data = $response->get_data();
// Păstrăm doar ce ne interesează pentru frontend
$clean_data = [
'id' => $data['id'],
'title' => $data['title']['rendered'],
'slug' => $data['slug'],
// Luăm doar câmpurile ACF relevante
'logo' => get_field('brand_logo', $post->ID),
'color' => get_field('brand_accent_color', $post->ID)
];
$response->set_data($clean_data);
return $response;
}Dacă ai făcut vreodată un magazin headless pe WooCommerce și a trebuit să adaugi CPT-uri (Custom Post Types) pentru branduri, review-uri extinse sau specificații tehnice complexe cu ACF, știi deja durerea. Din oficiu, WordPress îți scuipă în API toate mizeriile posibile: link-uri de rândul trei, metadata de autor, statusuri de revizii și alte câmpuri inutile.
La un proiect de anul trecut (un magazin de cosmetice cu vreo 8.000 de produse unde am mapat "Rutine de îngrijire" ca CPT), payload-ul JSON pe o pagină simplă trecea de 1.2MB. Enorm pentru niște Next.js edge functions care trebuiau să randeze totul instant.
Opțiunea 1: REST API curat prin filtre
Dacă mergi pe REST API-ul nativ (pentru că e stabil și nu vrei să instalezi încă 5 plugin-uri de GraphQL), nu lăsa câmpurile la voia întâmplării. În mod normal, când bifezi "Show in REST" în ACF sau CPT UI, WordPress îți aruncă tot obiectul acf în rădăcina postării, alături de alte 30 de chei de care n-ai nevoie pe frontend.
Soluția mea preferată e să folosesc filtrul rest_prepare_{post_type}. Pur și simplu decupez tot ce nu folosește frontend-ul și las doar ID-ul, titlul și fix câmpurile din ACF de care am nevoie.
Merge brici pentru că am economisit cam 70% din dimensiunea payload-ului pe rețea. Trade-off-ul sincer? Trebuie să scrii cod manual în functions.php pentru fiecare CPT nou pe care îl adaugi în proiect. Dacă ai 15 CPT-uri diferite, devine plictisitor și greu de întreținut.
Opțiunea 2: WPGraphQL și WPGraphQL for ACF
Aici e rețeta modernă. Bifezi Show in GraphQL în setările ACF și înregistrezi CPT-ul cu schema corespunzătoare. Primești exact ce ceri în query-ul de frontend și uiți de filtrele din PHP.
Dar atenție mare la baze de date mari. La magazinul ăla cu 8k produse, fără un plugin de query caching (cum e WPGraphQL Smart Cache) și un Redis configurat corect pe server, query-urile complexe de GraphQL cu relații între produse și CPT-uri ne ridicau timpul de răspuns al serverului (TTFB) la peste 1.8 secunde. GraphQL e extraordinar pentru developer experience pe frontend, dar pe backend pune o presiune masivă pe baza de date din cauza join-urilor complexe pe care le face sub capotă în WP_Query.
Cum alegi?
- REST API cosmetizat: Excelent dacă ai un magazin mic spre mediu, server de hosting shared sau VPS ieftin. E stabil, cache-ul HTTP (Cloudflare) se configurează super ușor pe endpoint-uri de REST.
- WPGraphQL: Perfect pentru echipe mari, unde frontend-iștii vor flexibilitate totală și ai buget de un VPS serios + Redis + WP Engine/Kinsta care să ducă query-urile grele.
Voi ce folosiți pentru headless-ul cu WooCommerce? Rămâneți pe REST-ul clasic cosmetizat sau ați trecut complet pe GraphQL?