<?php
// Inregistrare CPT optimizata pentru GraphQL si REST API
add_action('init', function () {
register_post_type('fisa_tehnica', [
'labels' => [
'name' => 'Fișe Tehnice',
'singular_name' => 'Fișă Tehnică',
],
'public' => true,
'show_in_rest' => true, // Expune in REST API
'show_in_graphql' => true, // Expune in WPGraphQL
'graphql_single_name' => 'fisaTehnica',
'graphql_plural_name' => 'fiseTehnice',
'supports' => ['title', 'editor', 'custom-fields'],
'menu_icon' => 'dashicons-pdf',
]);
});Anul trecut am preluat un frontend pe Next.js conectat la o platformă WooCommerce cu vreo 12k de produse și mai multe Custom Post Types pentru fișe tehnice și garanții B2B. Când am deschis DevTools pe pagina de produs, m-am crucit: un singur request de JSON avea 1.8MB. Aproape tot bloat-ul venea din câmpurile de ACF expuse aiurea prin REST API-ul nativ.
Dacă vrei o arhitectură headless decentă, trebuie să controlezi la milimetru ce date trimiți în frontend.
Problema cu ACF în REST API-ul nativ
Implicit, dacă instalezi un plugin gen "ACF to REST API", WordPress îți aruncă în payload absolut tot ce găsește în baza de date pentru postarea respectivă. Primești ID-uri interne, URL-uri de media neoptimizate, null-uri și structuri imbricate greu de mapat în TypeScript.
Dacă ești obligat să rămâi pe REST API, nu lăsa plugin-urile să-ți controleze payload-ul. Cel mai bine înregistrezi câmpuri custom folosind register_rest_field() și extragi strict valorile de care ai nevoie cu get_field().
Câștigi control total, dar dezavantajul e că trebuie să scrii cod boilerplate pentru fiecare câmp nou pe care îl adaugi în WP Admin.
De ce WPGraphQL schimbă jocul pentru WooCommerce și CPT-uri
Pentru proiectul respectiv, am renunțat la REST API-ul nativ pentru partea de catalog și am trecut pe WPGraphQL împreună cu extensia wp-graphql-acf. Schimbarea a fost radicală: payload-ul pe pagina de produs a scăzut de la 1.8MB la doar 42KB.
Ca să expui un CPT în GraphQL curat, trebuie doar să adaugi câteva argumente specifice în funcția register_post_type(). De restul (tipuri de date, relații între postări, categorii) se ocupă schema autogenerată.
În plus, autocompletarea din GraphiQL îți salvează ore întregi de ghicit denumirile câmpurilor din ACF în backend.
Trade-off-ul sincer: Caching și complexitate
GraphQL nu e un glonte de argint. Merge excepțional când ai frontend în React sau Vue și vrei să ceri exact ce afișezi pe ecran, fără request-uri cascadate.
Totuși, la un magazin mare, caching-ul de REST API la nivel de CDN (Cloudflare, Fastly) este incredibil de simplu de configurat pe URL-uri statice (GET /wp-json/wp/v2/fise-tehnice/123). La GraphQL, fiindcă toate query-urile sunt trimise prin HTTP POST pe /graphql, va trebui să configurezi Persisted Queries sau să folosești GET-uri cu query hash-uri ca să obții același hit-rate în cache.
Dacă echipa ta nu are experiență cu GraphQL, complexitatea suplimentară pe infrastructură s-ar putea să vă încetinească mai mult decât cele câteva milisecunde câștigate pe rețea.
Concluzie
Dacă construiești ceva mic, REST API curățat manual prin hooks este arhi-suficient. Dar dacă ai un proiect e-commerce măricel cu CPT-uri interconectate și zeci de câmpuri ACF, WPGraphQL e opțiunea cea mai sănătoasă.
Voi ce abordare folosiți în producție pe Headless WordPress? Ați rămas pe REST sau ați făcut tranziția completă la GraphQL?