<?php
// Expunerea curată a câmpurilor ACF într-un CPT fără tot zgomotul implicit
add_action('rest_api_init', function () {
register_rest_field('fise_tehnice', 'specificatii_curate', [
'get_callback' => function ($post_arr) {
$post_id = $post_arr['id'];
// Extragem doar ce ne interesează, fără obiecte mari serializate
return [
'sku' => get_field('sku_produs', $post_id),
'greutate' => (float) get_field('greutate_kg', $post_id),
'materiale' => wp_get_post_terms($post_id, 'material', ['fields' => 'names']),
'pdf_manual' => get_field('fisier_pdf', $post_id)['url'] ?? null,
];
},
'schema' => null,
]);
});Am refăcut recent arhitectura pentru un shop cu vreo 12.000 de produse și un CPT custom numit fise_tehnice, ambele legate masiv cu ACF Pro. Frontend-ul era trecut pe Next.js (App Router), iar când am pornit primul build, am crezut că s-a blocat pipeline-ul. Un singur request pe /wp-json/wp/v2/fise_tehnice aducea un JSON de aproape 4MB. Era plin de meta-uri inutile, links, variante de thumbnails nefolosite și toate câmpurile ACF posibile, adânc îmbrăcate în obiecte generice.
Dacă construiești un WooCommerce sau o platformă mai serioasă în mod Headless, răspunsul implicit generat de WordPress e pur și simplu un dezastru pentru performanță. Trebuia să curățăm totul rapid.
REST API sau WPGraphQL? Trade-off-ul real din producție
Mulți juniori sar direct pe WPGraphQL pentru că sună modern. Am căzut și eu în capcana asta acum 3 ani. WPGraphQL e absolut genial pe query-uri complexe unde vrei doar 3 câmpuri dintr-o relație și nimic altceva, scăpând de clasicul N+1 query problem. Dar vine cu o problemă mare la scară: caching-ul la nivel de CDN.
Request-urile de GraphQL sunt implicit POST. Când ai 8.000 de useri simultani pe site, Cloudflare nu-ți va face cache la POST-uri direct din cutie fără mizerii complicate. Pe de altă parte, REST API-ul nativ folosește GET. Îl pui în spatele unui Varnish sau Cloudflare Edge Rule și răspunsul îți vine în 15ms direct din memorie.
Trade-off-ul meu azi? Dacă am nevoie de căutări complexe și relații adânci în admin/dashboard, merg pe GraphQL. Pentru paginile publice de e-commerce cu trafic mare, folosesc REST API, dar obligatoriu curățat prin hooks.
Cum scăpăm de mizeria din ACF și REST
Implicit, extensia acf-to-rest-api aruncă tot ce găsește sub cheia acf în răspunsul JSON. Dacă ai un câmp de tip 'Flexible Content' sau 'Repeater', îți va serializa obiecte enorme cu tot cu datele de configurare ale câmpului.
Soluția curată nu e să instalezi încă 3 plugin-uri, ci să-ți creezi endpoint-uri dedicate sau să folosești register_rest_field ca să expui strict ce vrei. În loc să lași WP să livreze tot obiectul post-ului, filtrezi payload-ul la ieșire.
La proiectul de care vă ziceam, am dezactivat expunerea automată ACF în REST și am mapat manual doar ID-urile și valorile primitive (string, int, array simplu). Payload-ul per fișă tehnică a scăzut de la 3.8MB la 140KB. Build time-ul pe Vercel a sczut cu 35% doar din schimbarea asta.
Câteva sfaturi dacă ești la început cu schema GraphQL/REST
- Nu expune niciodată ACF automat în REST dacă ai câmpuri de tip
UsersauPost Objectfără să limitezi adâncimea. Risc de buclă infinită în memorie. - Folosește
graphql_single_nameșigraphql_plural_nameexplicite când înregistrezi un CPT prinregister_post_type(). Dacă lași denumirile implicite, schema devine oribilă. - Dezactivează rutarea nativă
/wp-json/wp/v2/postsdacă nu folosești postările clasice. Fără resurse irosite pe parsare.
Voi cum abordați arhitectura când aveți peste 10.000 de produse sau entități? Mergeți pe WPGraphQL cu Smart Cache sau preferați să vă scrieți endpoint-uri custom de REST?