Aem Content fragments

​@Sudeep, deep nesting in Content Fragments is a known anti-pattern in AEM Headless. Past two or three levels you hit GraphQL resolver fan-out, persisted query bloat, and fragmented caching that makes the structure expensive to deliver and harder to author. There are many patterns how you can do it, but here is how I would do it with limited knowledge about your setup.

Implement it via page tree plus shallow CFs. Use the AEM page tree as the source of truth for the menu hierarchy, the way AEM Sites traditionally handles navigation.

CFs hold only the content payload (label, link, image, description) for each node. Hierarchy is implicit in the page path. It aligns with how authors already think about site structure, and the page tree UI is far better than nested CF editing.

Hi ​@Sudeep ,

I would avoid creating a Content Fragment structure with 3-4 levels of nested Fragment References. While it may look like the natural way to represent a menu hierarchy, it makes GraphQL queries complex, impacts performance, and becomes difficult for authors to maintain. A better approach is to keep the Content Fragment model relatively flat. Store each menu item as an individual Content Fragment and use fields such as ID, Parent ID, Title, and Link to define the hierarchy. The GraphQL query can then fetch all menu items in a single request, and the application can build the menu tree using the Parent ID relationship. This approach keeps authoring simple, improves GraphQL performance, reduces dependency on deeply nested references, and allows the menu structure to grow without requiring changes to the Content Fragment model. In general, limiting Fragment References to one or two levels is a good practice for scalable and maintainable AEM implementations.