Performance issues with GraphQL queries. | Community
Skip to main content
R
Rajumuddana
Level 4
January 10, 2025
Solved

Performance issues with GraphQL queries.

  • January 10, 2025
  • 2 replies
  • 576 views

Hi Team,

 

There is a requirement in my Project where we are fetching 3rd party data using GraphQL.

This 3rd party data has properties details (which will be rendered as filters on page for end users). To make this Filters functionality works we need full data set at FE.

To get the full data set from 3rd party we need to make multiple calls, this led to performance issues.

We thought of using

  • 'server-side pagination’, since we need full data set at FE, this option is not suitable for us.
  • Persisted queries, doesn’t help much here (I guess).
  • Batching GraphQL queries, my 3rd party system doesn’t support.

Is there a better way to avoid these performance issues in this case?

 

Thanks,

Raju.

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 Tethich

Hi @rajumuddana 

1. From an architectural perspective, if your client digital ecosystem permits, I would say that introducing a cache server, as a layer in between your front-end and the 3rd party holding original data, would definitely help. This is will be used to store original data, alter it if you need to enhance/amend with information (like taxonomies, filters, properties etc) that will later serve implement desired functionalities like filtering, sorting or pagination and serve it to your front-end layer. In this way you could address the latency between front-end and client.

2. One other approach might be to bring data closer to your app, meaning to pre-import it from 3rd party into AEM and use GraphQL to consume it from AEM afterwards. But for this approach you might need to think of few things when saving dynamic data into AEM. I have raised these concerns in one of my recent responses to another thread: https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/acceptable-scheduler-frequency-in-aemaacs/td-p/729923

 

3. In addition, you can make use of local cache, like local/session storage, to improve website state.

2 replies

kapil_rajoria
Community Advisor
kapil_rajoriaCommunity Advisor
Community Advisor
January 10, 2025

Hi @rajumuddana, I suggest you to save the API response data in a file in AEM's Dam. You can then fetch the data from this file in front-end instead of calling the API again and again.
If the response data is dynamic, consider making a scheduler and update the file frequently according to your own requirement.

    Tethich
    Community Advisor
    TethichCommunity AdvisorAccepted solution
    Community Advisor
    January 10, 2025

    Hi @rajumuddana 

    1. From an architectural perspective, if your client digital ecosystem permits, I would say that introducing a cache server, as a layer in between your front-end and the 3rd party holding original data, would definitely help. This is will be used to store original data, alter it if you need to enhance/amend with information (like taxonomies, filters, properties etc) that will later serve implement desired functionalities like filtering, sorting or pagination and serve it to your front-end layer. In this way you could address the latency between front-end and client.

    2. One other approach might be to bring data closer to your app, meaning to pre-import it from 3rd party into AEM and use GraphQL to consume it from AEM afterwards. But for this approach you might need to think of few things when saving dynamic data into AEM. I have raised these concerns in one of my recent responses to another thread: https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/acceptable-scheduler-frequency-in-aemaacs/td-p/729923

     

    3. In addition, you can make use of local cache, like local/session storage, to improve website state.

      Terms & ConditionsAccessibility statement

      Loading footer...