graphql and content fragments | Community
Skip to main content
T
TB3dock
Level 8
March 23, 2021
Solved

graphql and content fragments

  • March 23, 2021
  • 1 reply
  • 1137 views

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

 

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Pawan-Gupta

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!!

1 reply

Pawan-Gupta
Pawan-GuptaAccepted solution
Level 8
March 23, 2021

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!!

    T
    TB3dockAuthor
    Level 8
    March 24, 2021
    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.
    Terms & ConditionsAccessibility statement

    Loading footer...