Postat acum 6 ore
Am făcut 6 proiecte headless WordPress în ultimii 2 ani. 3 cu REST, 3 cu GraphQL. Fiecare tabără are fani puternici — realitatea e pe la jumătate.
REST API (core WP)
Pro:
- Gratis, built-in de la WP 4.7
- Documentație excelentă, stable
- Suport bun cu cache la nivel de endpoint (Cloudflare, nginx)
- Orice plugin e expus automat prin
/wp-json/
Contra:
- Over-fetching — primești 30 câmpuri când vrei 3
- N+1 când incluzi relații (autori, categorii, media)
- Pagini custom cu meta field-uri → configurare manuală verbose
WPGraphQL
Pro:
- Selectezi exact câmpurile — payload mic
- Join-uri automate în 1 request
- DX grozav cu codegen TypeScript
- Exelent pentru pagini complexe (header + footer + content + sidebar într-un request)
Contra:
- Plugin third-party (deși matur)
- Cache la endpoint mai greu (toate request-urile merg pe
/graphql) - Schema regenerează la fiecare change de ACF → se pot rupe build-uri
Regula mea simplă
- Site marketing/blog, pagini relativ standard → REST. Cache agresiv, performance bun.
- Aplicație complexă cu Relații multe (produse + categorii + review-uri + meta) → GraphQL
- Client care schimbă content des → ambele cu ISR/revalidate
Gotcha #1 — preview în Next.js
WP preview e chin cu ambele. Trebuie:
- Endpoint custom
/api/previewcare autentifică cu token draftMode()în Next.js 16- Pagina randează cu date din preview, nu din cache
Gotcha #2 — ACF custom fields
- REST:
acf-to-rest-apisau?acf_format=standard - GraphQL:
WPGraphQL for ACF— funcționează out of the box
Gotcha #3 — paginare
- REST:
?per_page=12&page=2+ headerX-WP-TotalPages - GraphQL: cursor-based (
after: "cursor") — mai modern, mai complicat
Cache strategy recomandat
- ISR la nivel de pagină (
revalidate: 300) - Webhook de la WP → revalidatePath când publică ceva
- Cloudflare în față pentru visitors neautentificați (HTML-ul static)
Verdict
Pentru 70% din cazuri, REST + ISR ajung. Pentru aplicații cu relații complexe, GraphQL scoate vizibil mai multă performanță. Alege unealta pentru problemă, nu invers.