RFC - Static Generation / SSG Improvements

[danielcondemarin]

Problem

Next.js recently released a new API designed to improve Static Site Generation. More details can be found in vercel/next.js#9524.

serverless-next.js is not currently compatible with the new Next.js API and this RFC proposes changes to support these features.

Proposal

getStaticProps.

For pages that declares getStaticProps, Next.js generates a JSON file that holds the return value of executing getStaticProps. The file is used for client-side routing.

All JSON files for a given build can be found in .next/prerender-manifest.json.
serverless-next.js will lookup the files and upload them to S3 so they can be fetch-ed from the browser.
Also, a new cache behaviour will be created in CloudFront for the path pattern /_next/data/*. This will match any requests made to the JSON files and forward them to S3.

getStaticPaths

When you have a dynamic route you can add a method called getStaticPaths to the page. The way it works is Next.js generates a fallback HTML page that can be served when the route has not been pre-rendered on a previous request.

If the path is returned in getStaticPaths then is pre-rendered at build time. If is not pre-rendered at build time then it needs to be compiled server side in the background the first time the route is visited.

Here is a diagram to illustrate how this will work in serverless-next.js (fallback: true):

You can also set fallback: false. In this case a 404 is returned instead of pre-rendering:

getServerProps

getServerProps behaves similarly to getInitialProps. The difference is that on client side transitions, Next.js makes an api request to the server to run getServerProps and uses that to render the page client side.
In serverless-next.js this will be handled in the origin-request edge function as illustrated below:

Preview mode

Preview mode enables you to preview the "draft" of a page at request time rather than build time. Next.js achieves this by always calling getStaticProps on the page at request time whenever preview mode is enabled. Details of how to enable preview mode and use it can be found in https://nextjs.org/docs/advanced-features/preview-mode.

In serverless-next.js this will be handled in the origin-request edge function as illustrated below:

[janus-reith]

So in step 2, if not cached in cloudfront yet, it would always call the lambda and not S3 directy, right? How would the static fallback page be returned in that step, while the actual page is still rendered?

Also: Could it be possible to avoid calling the lamba, and just utilize that logic directly in cloudfront somehow, maybe by defining behaviours per page? So that Cloudfront could directly make calls to S3, and if a page is not present, serve the fallback page for that route, and still trigger that lambda for the page creation. Or if triggering the lamba is not possible, still do the initial lookup from S3, and if not present, call the lambda and make that serve the static fallback page while still creating the actual page. Or do the opposite, and serve the static fallback page from S3 and make that page trigger the lambda in its client side while it's in fallback mode and awaiting the page.

Although the overhead might be negligible as most things will be cached in Cloudfront, I was under the impression that the architecture would allow to always serve any request for a static page directly from file, without needing to call a function first, including the fallback and revalidate pages.

[danielcondemarin]

Hi @janus-reith Thanks for the questions! Made me realise a few things I didn't consider before.

Let me start with this:

Could it be possible to avoid calling the lamba, and just utilize that logic directly in cloudfront somehow, maybe by defining behaviours per page?

It is possible but wouldn't scale. CloudFront has a limit of 25 cache behaviours per distribution. It wouldn't work for apps with more than 25 page routes which is a fairly common use case.

So in step 2, if not cached in cloudfront yet, it would always call the lambda and not S3 directy, right? How would the static fallback page be returned in that step, while the actual page is still rendered?

Yes you are correct, it would call the lambda. Also, this question made me realise something I had missed. I assumed by setting callbackWaitsForEmptyEventLoop = false I could make Lambda@Edge forward the request onto S3 for the fallback whilst in the background generating the actual page. However from reading the docs AWS wouldn't actually run anything in the background. It freezes the execution context of the Lambda and up to their discretion it may resume in the next invocation any outstanding events.
There are other ways to approach this like using some sort of queue / polling mechanism (e.g. SQS) but I want to avoid adding more complexity to the architecture if possible.

I'll keep looking for solutions, any ideas are appreciated 🙏

[janus-reith]

Thanks for the explanation, I didn't know about that Cloudfront limit.

However from reading the docs AWS wouldn't actually run anything in the background. It freezes the execution context of the Lambda and up to their discretion it may resume in the next invocation any outstanding events.

Could my third suggestion work for this maybe?
Serve the static fallback page from S3 and make that page trigger the lambda on the client side while it's in fallback mode and awaiting the page.
I did'nt look it up exactly, but when the client recieves the static fallback page for a route, it does some call to the server and waits for a response when the actual page finished rendering. So that call could be trigger for the page creation I guess?
Im not sure if that actually is a good approach, because when the lambda is hit initially and could directly start creating the page that would be finished faster than to wait until the client recieved the fallback page and then sends a request that triggers the render, but that could be simpler to implement.

One could probably verify easily if default next start or Now deployments are doing that aswell by fetching a fallback page first time with disabled js, so if that client side call triggers the creation it wouldn't execute then. Then retry that request and check the output.
Update: Just tried that out on a Now deployment that has fallback enabled, and it does not seem to be the case, the pages were available on second request without a clientside fetch involved.

[danielcondemarin]

@janus-reith I may have a come up with a solution similar to what you suggested.

Let me know what you think 🙏

A few notes on this approach:

• It doesn't require updating the pre-render manifest whenever a new page is compiled.
• Optimises for the most common use case. origin-request edge function assumes the page has been compiled already and 404s are handled on origin-response.
• Latency when serving the Fallback page should be minimal -> single read roundtrip to S3.

cc. @oseibonsu

[janus-reith]

@danielcondemarin Im not sure about that last part where you get /blog/hello, it seems redundant if you already fetched the json.
I just checked that on a fallback page, and I can't see another document being fetched there either.
Therefore I believe that render would just execute clientside with the fetched json.

[danielcondemarin]

@danielcondemarin Im not sure about that last part where you get /blog/hello, it seems redundant if you already fetched the json.

That last part is just to illustrate what would happen if there is a second request after the actual page and JSON props file has been generated in step 2.
Also, there is a distinction between fetching via client side or doing a page load / refresh.
When client side, the JSON file is fetched like you said, but if you do a page refresh then the HTML document is served and no JSON file is requested.

[janus-reith]

Ah ok, yes I agree then, it wasn't clear for me in in the diagram - Maybe separate that third step from the other two which are connected? :)

[danielcondemarin]

Ah ok, yes I agree then, it wasn't clear for me in in the diagram - Maybe separate that third step from the other two which are connected? :)

I've updated the RFC with an updated diagram that provides description for each step so is more clear 👍

[HaNdTriX]

Afaik Next.js relies heavily on RFC5861 for serving stale content and revalidating pages in the background.

https://github.com/zeit/next.js/blob/18036d4e5198b6375a849c584c8b5a822ee41952/packages/next/next-server/server/send-payload.ts#L31-L47

Currently this extension is not supported by Cloudfront. Nevertheless it definetly would make sense to follow the RFC as close as possible.

[janus-reith]

@HaNdTriX I guess this would make it possible to skip the lamba and serve directly from S3 instead if available?

[danielcondemarin]

Afaik Next.js relies heavily on RFC5861 for serving stale content and revalidating pages in the background.

https://github.com/zeit/next.js/blob/18036d4e5198b6375a849c584c8b5a822ee41952/packages/next/next-server/server/send-payload.ts#L31-L47

Currently this extension is not supported by Cloudfront. Nevertheless it definetly would make sense to follow the RFC as close as possible.

@HaNdTriX I will be covering vercel/next.js#11552 on a separate RFC. Whilst CloudFront doesn't support stale-while-revalidate I suspect we can achieve something pretty similar using the Lambda@Edge origin-request and origin-response hooks.