[sitecore-jss][templates/nextjs] Handle rate limit errors in Layout and Dictionary Services through GraphQL Client

[art-alexeyenko]

• This PR follows the Contribution Guide
• Changelog updated

Description / Motivation

GraphQL endpoints can reply with a code 429 response when too many requests are launched (i.e. during static page generation). This PR adds a retryer functionality to GraphQL Client in sitecore-jss package to prevent 429 errors crashing a nextjs build.
To enable it, specify the number of retries for GraphQL services in dictionary-service-factory and layout-service-factory.

Retry will either read the 'Retry-After' header and send another request after the specified timespan, or use 1 second between retries by default.

Testing Details

• Unit Test Added
• Manual Test/Other (Please elaborate) - Limited testing with Throttling Strategies in Sitecore:
  https://doc.sitecore.com/xp/en/developers/103/sitecore-experience-manager/throttle-requests.html

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

[illiakovalenko]

What will happen in case of graphql-personalize-service, graphql-redirects-service, etc... all the services that are using GraphQLClient, since you covered only dictionary, layout services?

[art-alexeyenko]

What will happen in case of graphql-personalize-service, graphql-redirects-service, etc... all the services that are using GraphQLClient, since you covered only dictionary, layout services?

In case of personalize service that's intentional. We should not have personalize be slow, and if it fails it should fail fast, not wait for one second or more.
In case of others - it's mostly to not complicate the implementation and keep it as far as possible from being a breaking change. The main problem, and the main bulk of requests being sent are dictionary and layout service requests. By addressing those there should be a lot of breathing room for all the rest.
@illiakovalenko

[illiakovalenko]

@art-alexeyenko For example "redirects-service" is called on each request, like dictionary, layout services. What about this case?

[art-alexeyenko]

For example "redirects-service" is called on each request, like dictionary, layout services. What about this case?

I think retryer is not a good fit for a redirects-service either. Redirects is something that won't be updated too often, is something that isn't too large, and redirects are retrieved on per-site basis. With this, instead of bombarding GQL endpoint with retry redirects queries, it would be better to reduce how often redirect data is fetched - via storing it in app for a certain time. It would be better than retrieving all the redirects for every page render.