EXPERTISE / 04
Headless AEM & Structured Content Delivery
Headless delivery moves the rendering boundary; it does not remove content architecture. I focus on the model, API contract and publication behavior that let frontend consumers evolve without exposing AEM’s internal implementation as an accidental public interface.
Architecture and PoC design. The related Work scenario is explicitly a headless exploration, not a claimed production rollout.
ASSESSMENT FLOW
- Content models
- Author / publish
- API contract
- Dispatcher / CDN
- Frontend consumers
CONTENT ARCHITECTURE
Model meaning before choosing an endpoint
Start with the content consumers need, its ownership and its lifecycle. Define required fields, references, localization and what happens when a referenced item is unpublished. A content model should not merely reproduce a screen layout.
Content Fragments support structured content independent of page composition. Experience Fragments are relevant where reusable authored experiences matter; they should not be treated as interchangeable domain records. Keep presentation reuse and structured-content reuse as separate design decisions.
TECHNICAL COMPARISON
GraphQL or Sling Model Exporter?
Choose the contract that matches the source of truth. Neither approach fixes an unstable model or unclear access policy. A useful PoC implements one real consumer journey and tests a content change against it.
- GraphQL: a schema over Content Fragment models supports selected fields and references. Account for query governance, nested payload size and model evolution.
- Sling Model Exporter: a Java-backed JSON representation fits resource or component contracts. Account for coupling to resource types, model adaptation and serialization behavior.
- A separate JSON API can provide a deliberate integration boundary when neither content-model queries nor a resource export expresses the required contract.
| Decision | GraphQL | Sling Model Exporter |
|---|---|---|
| Source contract | Content Fragment schema | Resource / component model |
| Consumer selection | Fields and references within the schema | JSON exposed by the Java model |
| Change risk | Model and query compatibility | Resource type and serialization compatibility |
| Caching | Persisted GET queries with explicit cache policy | Export URL and headers with explicit cache policy |
DELIVERY
Design cache behavior with the API
A persisted GraphQL GET query can use Dispatcher and CDN caching when the delivery configuration permits it. That is different from assuming an arbitrary POST query will be cached. Include query parameters, locale and authorization in the cache analysis.
For an exporter response, test the actual URL, selectors, headers and invalidation behavior. A fast warm response says little about the cost of a cache miss. Check how a content update becomes visible and what a consumer sees when a dependency is missing.
- Bound payload size and nested references before measuring latency.
- Verify anonymous and authenticated requests cannot share inappropriate cached responses.
- Test publication, unpublication, stale responses and frontend fallback behavior together.
TRADEOFFS
Headless shifts responsibilities to consumer teams
Frontend applications take on rendering, routing, preview and parts of error recovery. Editors still need a credible preview and a clear publishing workflow. A hybrid implementation may be more appropriate when page composition remains central to authoring.
I would validate contract tests, model changes, permission boundaries and cache invalidation before expanding to more channels. The deliverable is a repeatable content-delivery contract, not simply a working API response.
ENGINEERING NOTES