<?php
// Inregistrare CPT optimizat pentru REST si WPGraphQL
add_action('init', function () {
register_post_type('produs_custom', [
'labels' => ['name' => 'Produse Custom'],
'public' => true,
'show_in_rest' => true,
'show_in_graphql' => true,
'graphql_single_name' => 'produsCustom',
'graphql_plural_name' => 'produseCustom',
'supports' => ['title', 'editor', 'thumbnail'],
]);
});
// Curatare payload REST API pentru a reduce dimensiunea JSON-ului
add_filter('rest_prepare_produs_custom', function ($response, $post) {
$data = $response->get_data();
// Scoatem campurile inutile pentru frontend
unset($data['meta'], $data['_links'], $data['guid'], $data['ping_status']);
$response->set_data($data);
return $response;
}, 10, 2);Am lucrat anul trecut la refacerea unui catalog complex pe WordPress headless cu frontend în Next.js, având peste 12.000 de produse și specificații tehnice custom. Prima chestie de care m-am lovit a fost latența API-ului: un singur request de REST API cu toate câmpurile ACF încărcate livra un JSON de aproape 2.5 MB. Frontend-ul se mișca oribil, iar serverul PHP intra în comă la 30 de request-uri simultane.
Dacă vrei o arhitectură headless scalabilă, nu poți lăsa WordPress să dea dump la tot ce are în baza de date. Trebuie să expui doar ce trebuie și să controlezi structura datelor.
REST API nativ: Util, dar plin de mizerie
Implicit, când pui 'show_in_rest' => true la un Custom Post Type (CPT), WordPress îți dă tot: conținut randat, statusuri, link-uri HAL (_links) și meta-date pe care frontend-ul modern nici nu le privește. Dacă adaugi și plugin-ul ACF cu opțiunea de expunere în REST, primești un obiect uriaș acf lipit de fiecare postare.
Soluția rapidă pe REST este să folosești un hook de rest_prepare_{$post_type} și să elimini din array-ul $response->data tot ce nu-ți trebuie. Am economisit cam 65% din dimensiunea JSON-ului doar curățând cheile nefolosite pe care frontend-ul oricum nu le citea.
Totuși, REST rămâne rigid. Dacă ai nevoie doar de titlul și două câmpuri ACF pentru o listă de paginare, REST îți trimite tot obiectul de fiecare dată.
GraphQL: Flexibilitate maximă, dar cu atenție la resurse
Aici intră în scenă plugin-ul WPGraphQL combinat cu WPGraphQL for ACF. În loc să faci 3 request-uri separate sau să primești un payload uriaș, ceri exact ce-ți trebuie pe frontend.
Când înregistrezi CPT-ul în functions.php, îi dai câteva argumente dedicate pentru GraphQL (show_in_graphql, graphql_single_name, graphql_plural_name).
Trade-off-ul sincer? GraphQL nu e un glonț de argint. Execuția unei interogări GraphQL complexe în PHP consumă considerabil mai multă memorie (CPU & RAM) decât un endpoint REST nativ. WPGraphQL construiește schema în runtime și procesează fiecare resolver în parte. La un proiect cu trafic mare, un query GraphQL necache-uit poate ridica timpul de răspuns la peste 800ms.
Cum alegi între ele?
Dacă proiectul e simplu și ai un CDN în față (cum e Cloudflare) care poate face cache agresiv pe URL-urile de REST API, mergi pe REST curățat manual prin hook-uri. E simplu de pus în cache și nu încarcă serverul PHP.
Dacă ai un UI complex, cu multe componente care cer fel și fel de combinații de date ACF, mergi pe GraphQL. Dar pune obligatoriu în față un strat de Redis sau WPGraphQL Smart Cache, altfel baza de date va suferi.
Voi ce abordare folosiți când legați WordPress de un framework JS? Ați rămas pe REST API optimizat sau ați trecut complet pe GraphQL?