Headless AEM: GraphQL and Sling Model Exporter Delivery Boundaries.

A consumer that needs reusable domain content has a different contract from one that needs page-component state. Define the required data and editorial workflow before selecting an endpoint.

Exporting page-shaped data can preserve a frontend dependency on the component tree. Conversely, a fully detached frontend must take ownership of routing, rendering and preview behavior that traditional AEM delivery may already provide.

Content Fragment models provide structured content for GraphQL queries. Sling Model Exporter exposes model data as an exported representation. Treat these as separate APIs rather than describing the exporter as the GraphQL implementation.

Select a small, representative content model and consumer view. Persist the required GraphQL query, implement the consumer mapping and independently evaluate a component exporter where page context is needed.

• Specify required fields, null handling and reference behavior.
• Test published content separately from authenticated author access.
• Inspect the actual request method, URL and cache headers at the delivery edge.

Stored queries executed through a suitable GET delivery path can support Dispatcher and CDN caching. Cache configuration and publication behavior still need explicit validation; persistence alone is not a cache guarantee.

Headless delivery can separate release cycles, but it adds consumer compatibility, preview and content-freshness decisions. Traditional rendering remains a reasonable choice when page composition and authoring control are the dominant requirements.

Before stabilizing an API contract, review Content Fragment fields, references and schema evolution.

The proposed PoC should demonstrate behavior, not just an endpoint returning a successful status.

• Test missing fields, empty references and unpublished dependencies.
• Compare cold and warm delivery and validate freshness after publication.
• Change a field in a test model and document the effect on the consumer.

A persisted query can remain valid while a content-model change breaks a consumer's assumptions about null fields or cardinality. Exercise old and new consumers against representative content, then validate cache keys, publication invalidation and permission boundaries before promotion.

An API is useful when editors understand what they publish and consumers understand what can change. Keep detailed schema evolution in the content-modeling study and cache policy in the Dispatcher study.

These sources document product behavior. The design and validation approach above are engineering proposals, not claims made by the vendors.

• Adobe: persisted GraphQL queries
• Apache Sling: Sling Models and exporters