Incremental static regeneration by kirkness · Pull Request #1028 · serverless-nextjs/serverless-next.js · GitHub

Adds Incremental Static Regeneration! Related issues #804 #995 Add unit tests for regeneration logic Test assumptions around how rollup.js bundles dynamic imports as per @dphang's comment Add e2e tests for ISR fallbacks Setup deployment of infra via serverless Add e2e tests Make code for ISR possible to be agnostic to the provider as per @dphang's comments Only pass what's needed to the queue as per comment from @jvarho Find a workaround for max 300 SQS calls per second (using lambda async invoke) Setup deployment of infra via CDK Create a demo site for reviewers - https://d3kjdl6gtxbc5l.cloudfront.net/about Update cache logic to handle changes to revalidate property, as per @dvarho's comment Load test the SQS queue to more than 300 requests in one seconds to test this assumption from @evangow - assumption was correct, it's max 300 API calls per second, will find a workaround Tidy-up code by moving duplicate code (for example the page generation code) into functions/seperate files The implementation looks like: At "origin response" we check whether the response page is an ISR page (has an Expires header, or the original build page had a revalidate property) We check whether the Expires header is in the future and if so apply a cache-control header such that the object is stored in the edge until its ready for revalidation. If the Expires header is in the past then we trigger the page to be regenerated, whilst still returning the existing page with no-cache To trigger a page rebuild we send a message to a FIFO SQS Queue, deduplicated using the identifier of the S3 object we are replacing so that we at most trigger one rebuild per page. FIFO SQS queues do come with a 300/second rate limit on all API Requests, which might be hit on very active sites, in which case we cache the page for an extra second to back-off requests. You can check out a demo of this feature here, check the headers and the response times to try to get your head around its behaviour. The code for this page looks like: export async function getStaticProps() { return { revalidate: 60, props: { date: new Date().toLocaleString() } }; } const AboutPage = (props: {date: string}) => ( // ... <p>This is the about page, and the time is about {props.date}</p> // ... ) export default AboutPage 👍

Incremental static regeneration by kirkness · Pull Request #1028 · serverless-nextjs/serverless-next.js · GitHub

Adds Incremental Static Regeneration! Related issues #804 #995 Add unit tests for regeneration logic Test assumptions around how rollup.js bundles dynamic imports as per @dphang's comment Add e2e tests for ISR fallbacks Setup deployment of infra via serverless Add e2e tests Make code for ISR possible to be agnostic to the provider as per @dphang's comments Only pass what's needed to the queue as per comment from @jvarho Find a workaround for max 300 SQS calls per second (using lambda async invoke) Setup deployment of infra via CDK Create a demo site for reviewers - https://d3kjdl6gtxbc5l.cloudfront.net/about Update cache logic to handle changes to revalidate property, as per @dvarho's comment Load test the SQS queue to more than 300 requests in one seconds to test this assumption from @evangow - assumption was correct, it's max 300 API calls per second, will find a workaround Tidy-up code by moving duplicate code (for example the page generation code) into functions/seperate files The implementation looks like: At "origin response" we check whether the response page is an ISR page (has an Expires header, or the original build page had a revalidate property) We check whether the Expires header is in the future and if so apply a cache-control header such that the object is stored in the edge until its ready for revalidation. If the Expires header is in the past then we trigger the page to be regenerated, whilst still returning the existing page with no-cache To trigger a page rebuild we send a message to a FIFO SQS Queue, deduplicated using the identifier of the S3 object we are replacing so that we at most trigger one rebuild per page. FIFO SQS queues do come with a 300/second rate limit on all API Requests, which might be hit on very active sites, in which case we cache the page for an extra second to back-off requests. You can check out a demo of this feature here, check the headers and the response times to try to get your head around its behaviour. The code for this page looks like: export async function getStaticProps() { return { revalidate: 60, props: { date: new Date().toLocaleString() } }; } const AboutPage = (props: {date: string}) => ( // ... <p>This is the about page, and the time is about {props.date}</p> // ... ) export default AboutPage 👍