Content Fragments: Best Practice for Dynamic Shop Detail Pages (2024)

[MIkolaj]

## Background
I'm working on implementing a shop catalog system in AEM where I need to handle multiple shop detail pages. Each shop's data is stored in Content Fragments based on a single "SHOP" model.

## Current Setup
- Multiple Content Fragments based on one Model (SHOP)
- Each Content Fragment represents a unique shop with different data
- Need to create individual detail pages for each shop
- Want to use Core Components for the page template

## Main Questions
1. What's the recommended 2024 approach for implementing dynamic detail pages using Content Fragments?
2. Is it possible/advisable to create ONE dynamic detail page template that:
- Uses a fixed template with Core Components
- Dynamically loads Content Fragment data
- Generates URLs based on shop name property (with duplicate prevention)
OR
3. Should I programmatically create individual pages for each shop using APIs?

## Additional Considerations
- Need to handle URL generation based on shop names
- Need a strategy for preventing duplicate URLs
- Want to ensure the solution is scalable for n-number of shops
- Looking for the most maintainable and performant approach

I'd appreciate insights from the community on current best practices and any potential pitfalls to avoid. If you've implemented something similar, I'd love to hear about your experience and lessons learned.

## Technical Environment
- AEM as a Cloud Service
- Using Core Components
- Content Fragment Model-driven approach

thanks for all the responses everyone

[Sh1ju · Accepted solution]

Using GraphQL is indeed a modern, flexible approach to implementing dynamic content in AEM, especially for scenarios like your shop catalog where each detail page needs data from multiple Content Fragments.

GraphQL allows you to fetch only the data you need for each shop in a single query, reducing the complexity of multiple REST calls or backend logic to retrieve different parts of the shop data. You can design a GraphQL query that pulls all relevant properties from your SHOP Content Fragment model and its associated data in one request.

Instead of creating individual pages, configure a single detail page template in AEM that leverages GraphQL to fetch data .

Since each shop is fetched dynamically, you can use a clean, SEO-friendly URL structure like /shops/{shop-name}, and pass the shopName directly to the GraphQL query.

With GraphQL, you can define clear caching rules for individual fields or queries, optimizing content delivery. 

[MIkolaj]

@Sh1ju  Thank you so much for the answer! After thoughtful search, I decided to use the suggested approach with my twist on top of it.

[Tethich]

Hi @MIkolaj 

Your CFs will reside in AEM in a location probably like /content/dam/brand/shops. Where you will have a structure like

- cf-shop1
- cf-shop2
...
- cf-shopN

• The path for each is always unique, AEM makes sure of that. So the path will represent your unique URL. So you can use the cf node name for url to address the URL duplication concern.
• Assuming all you pages will have same structure, then it is desirable to have one template that represents a shop type page.
• In order to load different CF data depending on what page was called, you can add a Filter, that will act like a bridge, that catches your URL and it will lookup appropriate CF based on it.
• Let's say you will have a page like http://www.domain.com/shop1. The shop1 is your slug, Filter will catch this, extracts the slug from URL, and then looks up in the /content/dam/brand/shops for the cf-shop1.
• Of course location to shop CFs is something that it will need to know a priori. Same for cf- prefix, if you choose to append anything to the slug, before or after, it doesn't matter.
• After Filter finds the CF, it shares the data with the page somehow (maybe put some flag in JCR, or put data on request...you will need to see how is best for you).
• Then the component will know which data to pick up and show. Problem here is with the Core components. I dunno how this could be done without a custom component with its own Sling Model and so on. You can try.
• This solution will allow you avoid creating one page for each shop. So no need to programmatically create individual pages.
• In addition, if you want to have one shop that is a little different then the rest, and contains extra components, you will need to create a physically page for that. Cause when using a bridge Filter, you will not have any real page to edit.

I hope this untangles you a little bit and gives you an idea of the full solution that best fits your requirements.