A modern headless e-commerce powerhouse — leveraging WordPress and WooCommerce as a flexible backend, powered by GraphQL APIs, and delivering a blazing-fast React.js frontend experience.
As a developer building a headless WordPress + WooCommerce stack powered by React and GraphQL, I’ve had the opportunity to dissect both the power and the pain points of this architecture.
This section outlines my personal perspective, rationale, and key lessons for anyone considering or currently working with a headless WooCommerce setup.
Going headless gives me full control over the frontend — performance, design, and UX — without being limited by WordPress themes, PHP templates, or WooCommerce shortcodes.
- 🔥 Performance: React renders fast, supports code splitting, and boosts Core Web Vitals.
- 🧠 Developer Experience: Modern tooling, reusable components, API-first development.
- 🎨 Custom UX/UI: Freedom to create tailored product, cart, and checkout flows.
- 🔌 Decoupled Architecture: Clean separation between backend data and frontend display.
In our headless setup, WooCommerce becomes the eCommerce backend — not the frontend renderer.
It powers:
- ✅ Product and variation management
- ✅ Pricing, stock, SKU, and inventory
- ✅ Categories, tags, and attributes
- ✅ Orders, coupons, and shipping settings
All rendering and user experience happens in React, powered by WPGraphQL + WPGraphQL for WooCommerce.
| Feature | Status in Headless |
|---|---|
| Shortcodes / Gutenberg Blocks | ❌ Unsupported |
| WooCommerce templates (PHP) | ❌ Not used |
| Default cart/checkout pages | ❌ Must rebuild |
| My Account page / Order history | ❌ Must rebuild |
| Plugin-based UI enhancements | ❌ Must reimplement |
| Plugin Type | Works Headless? | Notes |
|---|---|---|
| Product meta / ACF fields | ✅ Yes | Query via GraphQL |
| Taxonomy-based enhancements | ✅ Yes | Tag, category, attributes |
| Stripe, PayPal, Square plugins | ❌ No | Use native SDKs in React |
| Subscription, booking plugins | Needs REST or custom GraphQL | |
| UI checkout enhancements | ❌ No | Must replicate manually |
I'm still actively exploring how best to handle checkout and cart workflows using GraphQL and/or direct SDKs. This area is evolving and will require additional architectural decisions and experimentation.
For any plugin or checkout customization, I plan to:
- Use
register_graphql_mutation()in PHP - Expose only the required input fields
- Trigger WooCommerce logic (
wc_create_order(), add metadata, etc.) - Return the necessary data to the frontend
This gives me precise control over WooCommerce data and plugin integrations without relying on PHP templates or REST when not needed.
- Headless WooCommerce isn’t “just” headless WordPress — it’s deeper and more involved
- You must understand WooCommerce internals (order lifecycle, stock, metadata)
- GraphQL is great, but not all WooCommerce logic is exposed by default — expect to write custom resolvers
- Checkout and cart logic are still in-progress and require thoughtful architecture
Would I go headless again? Absolutely — with context.
Going headless with WooCommerce is worth it if you:
- Need custom UI/UX
- Want fast, modern frontend performance
- Can own the integration layer (GraphQL, SDKs, order logic)
- Understand that Woo becomes your commerce engine, not your full-stack renderer
This stack isn’t for everyone, but if you’re building something custom, scalable, and API-first — headless WooCommerce is a strong choice.
- 📝 WordPress (Headless CMS)
- 🛒 WooCommerce (E-commerce plugin)
- 📡 WPGraphQL & WPGraphQL WooCommerce (GraphQL API for WordPress and WooCommerce)
- ⚛️ React.js (with Vite)
- 🚀 Apollo Client (GraphQL client)
- 🔀 React Router (SPA routing)
- 🎨 Bootstrap 5 (UI framework)
- 📬 Postman (for API testing)
- 🔐 dotenv (environment variable management)
api/- WordPress backend folder with minimal theme files (index.php,functions.php,style.css)client/- React frontend built with Vite