Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

graphql and content fragments

Avatar

Level 9

If a site has say 500 game info pages, all using the same page template, all with the same layout, and all with the same the same properties (title, short description, game Id, game type, game large image, game small image etc), it would be great if a front end app could query a subset of these, e.g. to show small image and short description for games of a particular type.

 

This could be done with a custom sling servlet, but the params, search query and response fields would be hard coded.  

 

We understand that to use graphql, which would seem perfect, requires that the content not be a page, nor a component, nor an experience fragment, but a content fragment.

 

Would it make sense to model game info pages with a generic template, which has an experience fragment, which contained a content fragment, just to be able to use graphql to query the data dynamically?

 

We have found that there is a "bug" where content fragment images are not responsive, which would be a show stopper for using this feature unfortunately:

https://github.com/adobe/aem-core-wcm-components/issues/728

 

1 Accepted Solution

Avatar

Correct answer by
Level 9

Hello,

 

Just want to share my thoughts, if it helps (based on my understanding)

 

GraphQL is great and mainly when it comes to 

- filtered query (where you just want to select certain property in return response)

- joining multiple queries along with above (means not querying multiple times to fetch desired results)

 

from above first option does fit your scenario because through REST call you must be fetching all the unnecessary data and then filter it to just get image and description for all different categories.

 

Now, it is again trade off between cost of query (based on number of resources and number of times you are running those query) along with frequency of content changes Vs Value of GraphQL based implementation and gain from it (you can observe it better)

 

So, if this component/functionality has been

- used multiple places

- running queries multiple times

- increasing number of resources in future

- facing performance issue (or likely to be)

 

then i would agree for the solution.

 

thanks!!

View solution in original post

2 Replies

Avatar

Correct answer by
Level 9

Hello,

 

Just want to share my thoughts, if it helps (based on my understanding)

 

GraphQL is great and mainly when it comes to 

- filtered query (where you just want to select certain property in return response)

- joining multiple queries along with above (means not querying multiple times to fetch desired results)

 

from above first option does fit your scenario because through REST call you must be fetching all the unnecessary data and then filter it to just get image and description for all different categories.

 

Now, it is again trade off between cost of query (based on number of resources and number of times you are running those query) along with frequency of content changes Vs Value of GraphQL based implementation and gain from it (you can observe it better)

 

So, if this component/functionality has been

- used multiple places

- running queries multiple times

- increasing number of resources in future

- facing performance issue (or likely to be)

 

then i would agree for the solution.

 

thanks!!

Avatar

Level 9
Thanks for the thoughts. interestingly, content fragments seem to have a major issue, that their images are not responsive. https://github.com/adobe/aem-core-wcm-components/issues/728. This would prevent us using them unfortunately.