Content Fragment and Experience Fragment Strategy for a Headless + Web Channel
A travel company needs to publish destination content to (a) its AEM Sites web experience, (b) a native mobile app via GraphQL, and (c) a partner API. Editors currently duplicate content: they write a destination article as a page, then re-key the same facts into a content fragment for the app. Product data (price, availability) lives in a separate PIM and changes hourly. Marketing wants to compose landing pages from reusable destination 'cards' that show live price. The team has 6 editors and no dedicated backend developers; the mobile team owns the GraphQL consumers.
1. Define the content model: what should be a content fragment, what should be an experience fragment, and what should stay a page?
Read the worked answer
Content fragments (structured, channel-agnostic data):
- Destination article body and attributes (name, region, highlights, hero image reference, SEO fields). This is the single source of truth consumed by web, app, and partner API via GraphQL. Editors stop re-keying.
- Model the fragment with a clear schema; use fragment references for related destinations.
Experience fragments (reusable presentation with layout):
- The destination 'card' and landing-page sections where layout and variation matter. XFs can reference a content fragment and render it, so the card's data comes from the CF while the card's layout/variants live in the XF.
- Use XF variations for channel-specific presentation (web vs app) where the same composition is reused.
Pages:
- The assembled web landing pages themselves (page = composition of XF/CF components plus page-level metadata and URL structure). Pages are the web delivery artifact, not the content source.
Not in AEM: live price/availability. That stays in the PIM and is fetched at render/request time (see next task).
2. How should live PIM pricing be integrated so the web card, app, and partner API all show consistent, fresh prices without hammering the PIM?
Read the worked answer
Keep PIM as the system of record; expose it through a caching integration layer.
- Server-side integration service (AEM-side or a thin middleware) that calls the PIM and caches responses for a short TTL (e.g., 60s) keyed by destination+date. This protects the PIM and gives all channels one consistent price view.
- Web: the destination card component fetches price from the integration layer at render, with Dispatcher/CDN caching aligned to the price TTL. Because price is hourly-changing, use short TTL + targeted invalidation rather than no-cache. Do not bake price into the content fragment.
- App / partner API: expose price through the same integration layer (GraphQL resolver or REST) so mobile and partners get identical values and caching semantics. The mobile team consumes the resolver, not the raw PIM.
- Consistency contract: define one freshness SLA (e.g., 'price no older than 5 minutes') and enforce it in the integration layer, not per channel.
- Failure mode: if PIM is down, serve last-known price with a staleness flag rather than an error, and log it.
This avoids three channels each integrating the PIM differently and drifting.
3. What risks does this model introduce for the 6 editors, and how do you mitigate them?
Read the worked answer
- Two-authoring-surface confusion (CF vs XF vs page). Mitigation: clear editor guidance and templates that make the intended path obvious; pre-wire XF cards that reference CFs so editors edit data in one place.
- Orphaned fragments / broken references. Mitigation: reference-aware publishing and a periodic orphan report; enforce that fragments are published with their referencing pages.
- Schema changes breaking the mobile GraphQL consumers. Mitigation: version the content fragment models / GraphQL schema, deprecate rather than remove fields, and coordinate with the mobile team before model changes.
- Price appearing 'wrong' on cached pages. Mitigation: documented freshness SLA, visible 'updated at' where appropriate, and short TTLs on price-bearing surfaces.
- Governance load on a small team. Mitigation: a named content model owner among the 6 editors, a change-review step for CF model edits, and automated validation in CI.