2

The original question was posted at Github discussion. But no one has answered the question yet. So let's try my luck here.

Context

I am trying to build a platform (a.k.a. web-2.0) website, where users will create the majority of the content, say like Ebay. I have decided to use useSWR to fetch the user-specific data after a page is loaded. Now I am choosing between getStaticProps and getServerSideProps for loading the cacheable and SEO-able page skeleton data.

getStaticProps generates HTML and JSON files, both of which can be cached by a CDN for performance.

From the doc, it doesn't elaborate on how exactly getStaticProps with CDN should be served in production. I am wondering if it is referring only to the pure static blog-like web pages, which don't use fallback nor regeneration. I have a feeling that getServerSideProps with CDN in front of server/lambda might be an easier and more performant cache architecture.

Question

Should NextJS getStaticProps with fallback and regeneration be used to serve a user-made-content web app?

To have the answer of this question, I believe I will need to understand a few things first:

Things I don't know and I can't find any related documentation

  1. How exactly pages with getStaticProps, fallback, and regeneration should be served with CDN as the doc above mentioned?
  2. Do the network requests have to always go through NextJs when using fallback? Are there examples of putting CDN of prerendered pages in front of server/lambda meanwhile supporting fallback & regen? My idea is to avoid server hits and save even more processing time & resources when there is a prerendered page.
  3. Does fallback and regeneration support saving the newly generated HTML and JSON in a remote store like S3, and make NextJS read from it?
  4. If the answer is no from question above, when serverless, say Lambda, how does it reuse the newly generated files? Does it rely on non-cold Lambda container memory/state? When with servers, can I share the newly generated artifacts across servers?

I could have missed some of the docs. Any clues, links, or corrections will be appreciated.

Thanks in advance =]


Update

I have found more information as below

  1. Serverless NextJs curret architecture
  2. Serverless NextJs RFC on fallback
  3. NextJs RFC on Incremental Static Regeneration

For the remaining questions, I have raised them to NextJS at this post.

Ivan Wang
  • 8,306
  • 14
  • 44
  • 56
  • It looks like they may be expecting you to deploy on Vercel--hopefully these features work on other environments too though. – Robert Moore Jul 04 '20 at 15:26
  • @RobertMoore I am more than happy to deploy on Vercel if they can explain how the Vercel solution is thoughtful and performant. Base on the lack of docs, I have a feeling that CDN with fallback and regen might be not optimized, or even not utilized at all. – Ivan Wang Jul 06 '20 at 08:14
  • 1
    With Vercel, your static pages (even the dynamically generated static pages) should be spread across their edge network/CDN for maximum speed. – Robert Moore Jul 06 '20 at 18:01
  • @RobertMoore how does it support fallback and regen? If it's CDN in front of server, then regen will never get hit? If it's CDN behind the server, i.e. server tell users to fetch from CDN address, then it is still 100% CPU hit on every request. For the later case, wouldn't getSeverSideProps with CDN in front of server be simpler and with about the same or even better performance? – Ivan Wang Jul 09 '20 at 06:10
  • 1
    With Vercel I am pretty sure the CDN is in front of the server. The way they solve the freshness problem with the CDN in front is with incremental static regeneration https://nextjs.org/blog/next-9-4#incremental-static-regeneration-beta – Robert Moore Jul 09 '20 at 14:32
  • @RobertMoore if CDN is in front of server, how does regeneration get triggered. Won't the users just get static artifacts from cache instead of hitting CPU? And is regen going to push the artifacts to CDN instead of being passively hit? – Ivan Wang Jul 20 '20 at 23:22
  • 1
    It gets triggered on a regular basis according to the `unstable_revalidate` parameter. Yes it looks like regen pushes the artifacts to the CDN rather than waiting for a request and then regenerating. – Robert Moore Jul 21 '20 at 15:30

0 Answers0