Headless WordPress Isn’t Enough (Here’s What’s Missing)

Source: Dev.to

The Promise of Headless WordPress

When I first moved to headless WordPress, it felt like a huge upgrade:

• No more theme constraints.
• It just worked.

The Hidden Complexity

After a few projects, I noticed a new problem. Headless WordPress removes one layer of complexity… but it shifts that complexity elsewhere. Now the frontend is responsible for:

• Fetching data
• Shaping responses
• Handling authentication
• Managing consistency across endpoints

If you build multiple frontends, you end up repeating that logic every time.

What Headless WordPress Does Well

• Decoupling the UI
• Improving performance (especially with static site generators)
• Giving frontend flexibility

These are genuine benefits, but they don’t answer the question: where does application logic live?

The Fragile Default Architecture

Typical setup:

Frontend → WordPress REST API

Simple, but fragile. The frontend becomes:

• Data layer
• Logic layer
• Presentation layer

all at once.

Introducing an Application Layer

To avoid duplication and fragility, I added a middle layer:

Frontend → Application Layer → WordPress

What the Application Layer Provides

• Standardized data access
• Centralized logic
• Reusable behavior

KiwiPress: Defining the Missing Layer

KiwiPress is my attempt to formalize this middle tier. Instead of each frontend talking directly to WordPress, they interact with structured services:

• WPRead – read operations
• WPCreate – create operations
• WPUpdate – update operations
• WPDelete – delete operations

Each service has a clear responsibility, eliminating duplication and guesswork about where logic resides.

Benefits of the KiwiPress Approach

• No duplication of logic across frontends
• Consistent data handling
• Easier scaling across projects
• A single source of truth for behavior
• Cleaner frontends
• Simpler swapping of rendering strategies

Now I can move between:

• Static builds
• Single‑page applications (SPAs)
• Server‑rendered apps

…without rewriting core logic.

Complementing Static Site Generators

KiwiPress doesn’t replace SSG frameworks like Next.js, Astro, or Gatsby; it complements them.

• SSGs handle rendering, performance, and delivery.
• KiwiPress handles structure, logic, and consistency.

Conclusion

Headless WordPress is a step forward, but it’s not the final step. If WordPress serves only as a data layer, we still need something to define the application layer—that’s what I’m building toward. Headless solves separation; the structure remains our responsibility, and that’s where things usually fall apart.