Rate limit issue deploying Next.js to Vercel using getStaticProps()

Viewed 1087

Using Next.js hooked up to Apollo, I have a good 50 or so non-dynamic URLs fetching data using getStaticProps(). It works wonderfully, and I love how the pages load in. The issue I am facing is that because Vercel builds the static versions of these pages at build, I quickly reach the rate limits for the API being used on those pages after about 40 are built. Given I don't have control of those rate limits, is there any way to throttle my data calls in each getStaticProps to space out those data calls at build time? My getStaticProps looks something like this on each page:

export async function getStaticProps() {
  const apolloClient = initializeApollo()

  await apolloClient.query({
    query: XXXXXXX,
    variables: {handle: "XXXXXXX"}
  })

  return {
    props: {
      initialApolloState: apolloClient.cache.extract(),
    },
    revalidate: 1,
  }
}

Everything works fine, or was when I had less pages and didn't have enough pages to hit the rate limit.

2 Answers

I ended up throttling my requests by 100ms by throwing a setTimeout with my request in it, inside of a promise. Worked exactly as intended during production build.

const sleep = (milliseconds, apolloClient) => {
return (
    new Promise(function(resolve, reject){
        setTimeout(() => {
            const request = apolloClient.query({
                query: XXXXXX,
                variables: {handle: "XXXXXX"}
            });
            resolve(request);
        }, milliseconds)
    });
)

};

export async function getStaticProps() { const apolloClient = initializeApollo()

await sleep(200, apolloClient)

return {
  props: {
    initialApolloState: apolloClient.cache.extract(),
  },
  revalidate: 1,
}

}

Without any configuration, the NextJS build will attempt to do some sort of multithreading, which results in multiple simultaneous HTTP requests at build time and the potential for overwhelming the receiving server. I don't know what the default configuration is here or how it depends on the build server.

The following NextJS configuration in your next.config.js will force the build process to single-thread when it is cycling through the getStaticProps and getStaticPaths requests:

    ...
    experimental: {
        workerThreads: false,
        cpus: 1
    },
    ...

You can find some additional information about this configuration here: https://docs.uniform.dev/sitecore/deploy/how-tos/how-to-control-nextjs-threads/

In my experience, this should significantly decrease rate limit issues with the content server.

Related