Is it possible to use another hosting provider than Vercel with incremental builds?

[jordyvandomselaar]

The company I work for is looking into AWS and would prefer to manager everything through AWS. Is it possible to use incremental builds/static exports with AWS?

[balazsorban44]

https://github.com/danielcondemarin/serverless-next.js

This might help, not sure about the incremental bit. Right now it looks like Next.js's success heavily relies on tight integration with the Vercel platform, and there is no official support for other hosting solutions with all the same benefits.

[jordyvandomselaar]

next start supports incremental generation and regeneration

That's really cool =), when using next start, I assume it exports static files as it goes then? So then we would need a watcher to check if there are new files to send them through a CDN?

[balazsorban44]

I had a chat with @Timer, and he convinced me that next start is a great option if choosing other platforms and my previous answers were based on my bad understanding around the docs.

Yes, it generates static files in the .next folder. After talking with @Timer, as I understood, ALL your requests to Next.js can be sent through a CDN.

[jordyvandomselaar]

But you would need next start to be running which you can't do on a CDN? You would need to send the contents of .next to a CDN?

[timneutkens]

You need an enterprise-grade CDN that supports caching dynamic responses (which is expected if you're going to host any app yourself). Vercel provides an enterprise-grade CDN to you out of the box for free and integrates with Next.js automatically when you deploy on Vercel.

[jordyvandomselaar]

Thanks for the explanation! I'm a happy user of Vercel myself and I'm just considering our options for when I pitch the idea for projects =)

[JonCognioDigital]

I'm not sure I understand the bit about "Next Start", AFAIK that's just a CLI command used to start Next?

I have a NextJS site hosted on Azure and have the ability to call a webhook from my CMS when content is updated but how could that webhook be set up and how could it trigger a re-build on an already deployed site?

[balazsorban44]

This is not yet implemented, but it may be available in the future: #11552 (reply in thread)

What you have for now is a time-based revalidation.

Meaning, if you return unstable_revalidate: 1 (the number being the time in seconds after which you want to revalidate) from getStaticProps, the page will be regenerated IN THE BACKGROUND. So the user will always be served with a static file.

Just an idea:
You could maybe trigger an update anyway, if your CMS changes, you can then send a crawler to that page of your site, so the "next real user" will have the same updated version as in the CMS. This is not tested, and I just assume this would work. @Timer what do you think?

[JonCognioDigital]

I like the crawler idea. I assume that once the revalidate time expires (which could be Googlebot) they will still get a statically served page, it just might not be up to date?

[revskill10]

@balazsorban44 Good idea, but i think it currently only solve the fallback: true part for newly created content, not the revalidation part. We still have to wait till event -based revalidation trigger implemented then a crawler will achive our result :)

So, with that idea, i think we need a special route to trigger validate the pages by crawling the path.

Something like this might work:

export const getStaticPaths() {
  const paths = ...
  const revalidatedPaths = ... // same format as paths
  return {
    paths,
    revalidate: revalidatePaths
  }
}

So only request to revalidatePaths will trigger the regeneration when in need.
But those revalidatePaths need to keep in private with a private header key,... so that we could setup an event trigger from CMS to post to those revalidatePaths

@timneutkens How do you think about this idea ?

[balazsorban44]

I would assume the event comes from your CMS, not from Next. So my idea:

1. change in CMS
2. a crawler picks up the event, "page x has been updated in CMS"
3. crawler visits your page x on Next.js
4. revalidation in the background
5. user gets fresh page

[balazsorban44]

This might not be the right thread to discuss this though, there is #11552. I just had a quick idea for @jon64digital's question.

[usagi-f]

I want to make the Incremental Static Regeneratoin work properly with AWS solution, but I'm concerned about the relationship between the number of seconds set by revalidate and the TTL setting of CDN (actually Cloudfront).

If CDN has a long TTL more than revalidate value, even if regenerated, then I think the cache(old html) will be prioritized.

However, If set the short revalidate value(e.g. 1sec) and also make TTL is same, the original merit of the CDN will be lost.

My understanding has any structual mistakes?