graphql and content fragments

Avatar

Avatar

TB3dock

Avatar

TB3dock

TB3dock

23-03-2021

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

 

Accepted Solutions (1)

Accepted Solutions (1)

Avatar

Avatar

rush_pawan

Avatar

rush_pawan

rush_pawan

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

Answers (0)