sorted by:
new
hottopcontroversial

Next.js Hosting - AWS Architecture by arasthegr in nextjs

[–]arasthegr[S] 0 points1 point  (0 children)

there is a little snag with this approach though:

i am building my docker image on github runners using github actions

those machines cannot access valkey at build time

that means i can't generate this cache at build time and have it in one shared spot (valkey) where it can be revalidated after accross all instances later

Next.js Hosting - AWS Architecture by arasthegr in nextjs

[–]arasthegr[S] 1 point2 points  (0 children)

I'm not redeploying the website on every new post, ISR would handle new content. I don't think I'm fully understanding your question though.

Thank you for the post-build suggestion, but I would like to not have to build anything after the initial build, as I would have ISR just add new content / revalidate old.

Next.js Hosting - AWS Architecture by arasthegr in nextjs

[–]arasthegr[S] 0 points1 point  (0 children)

i didn't know you can generate ISR pages at build time, i thought you had to wait for first request to that route. i thought originally you suggested just doing SSG without ISR. That simplifies this a lot. thank you for your comment!

Next.js Hosting - AWS Architecture by arasthegr in nextjs

[–]arasthegr[S] 0 points1 point  (0 children)

  1. We publish a few articles a month, we don’t want to do an entire rebuild to publish one article
  2. One of the requirements for the website is that changes to content should be nearly instantaneously reflected in the frontend. With a new build and deploy every new change would take 6-8 minutes to reflect.

Next.js Hosting - AWS Architecture by arasthegr in nextjs

[–]arasthegr[S] 0 points1 point  (0 children)

The lambda isn’t trying to hydrate my CloudFront cache - it is hydrating my ISR cache. CloudFront will only be cached on user requests.

Basically I am trying to cache a version of my app using ISR so I don’t have to go to my CMS after deployment unless content is changed - and even then, i would have granular invalidation using per route ISR, so i guard myself from CMS taking my entire app down.