Statically Generated Sites & webhook-based on-demand page revalidation #105
Conversation
Pushing these commits because I can't make sanity.io Sanity trigger webhooks to local addresses.
'fallback: true' breaks build.
|
This pull request is being automatically deployed with Vercel (learn more). structured-content-2022-web – ./web🔍 Inspect: https://vercel.com/sanity-io/structured-content-2022-web/HFwRMZuMefzjiSGRngNoFa7Xmxfq structured-content-2022-studio – ./studio🔍 Inspect: https://vercel.com/sanity-io/structured-content-2022-studio/46Phw4sampMxQ8sSEZLfzoxQXQmP |
There was a problem hiding this comment.
Nice to see the return of static generation. It took a while before I realized that this was no longer used once [[...slug]].tsx replaced the individual pages (about.tsx etc), but at some point it dawned on me that the Lighthouse scores were quite a bit lower than before.
(Also, a nice side-effect of getting an upgraded Next.js is that they fixed their <meta charset> placement. Previously there were all sorts of other tags before it, but to be valid HTML it's really supposed to be located within the first 1024 bytes of the document.)
Mainly I'm just wondering if articles have been forgotten here or if it's outside of scope/there will be a separate PR for it. But I also added some other minor comments.
How will this work with other PR branches in the future if we need to test with some updated content? Is a manual redeploy in Vercel the way to go about it then? Could it be worth putting the answer in the web README?
Documents how to setup GROQ webhooks that revalidates ISR routes on-demand. It's trivial to do this for posts as you only need to lookup the `slug` based on the `id` you receive in the webhook payload. When editing authors the GROQ query demonstrates how you can do a reverse lookup (find all pages that reference the edited author) then invalidate their routes. This work is based on sanity-io/structured-content-2022#105, thanks @j0nas! 🎉 [Test **Deploy with Vercel**](https://vercel.com/new/git/external?repository-url=https://github.com/stipsan/next.js/tree/add-on-demand-ISR-to-cms-sanity/examples/cms-sanity&project-name=cms-sanity&repository-name=cms-sanity&env=NEXT_PUBLIC_SANITY_PROJECT_ID,SANITY_API_TOKEN,SANITY_PREVIEW_SECRET,SANITY_STUDIO_REVALIDATE_SECRET&envDescription=Required%20to%20connect%20the%20app%20with%20Sanity&envLink=https://vercel.link/cms-sanity-env) ## Documentation / Examples - [x] Make sure the linting passes by running `yarn lint` Co-authored-by: Lee Robinson <9113740+leerob@users.noreply.github.com>
Statically Generated Sites & webhook-based on-demand page revalidation
Intent
Description
Instead of constructing Pages on-the-fly for every user, we fetch all Routes and their associated pages, and generate them at build-time.
I've set up two webhooks in the Sanity project's settings. The enabled webhook pings the /api/revalidate endpoint of this branch's latest Preview Deploy whenever anything in Studio is changed. When the endpoint is called, we have to find the Routes associated with the updated content and get the
slug.currentof these Routes. Then the magic happens; we callunstable_revalidateon each slug, which rebuilds the relevant Routes.This setup seems perfect for Sanity. The addition of
unstable_revalidatein Next.js v12.1 could not have been better timed. I'm quite happy with how smoothly this setup seems to work, the performance benefits are massive when compared to every user having to wait for every query on every page load and navigation.(The disabled webhook is to be enabled when this PR is merged.)
Article pages will be handled in a separate follow-up PR once the approach taking in this PR is approved.
Testing this PR
When testing this PR, make sure that you're on the Preview Deploy that's got the branch name, and not the latest shorthash; these are not the same, and I wasted some time being puzzled at "suddenly-broken webhooks" before I realized this. 😅
(/sections-testing and /shared-sections are useful Routes for testing)
[POST] /api/revalidaterequest is logged in the Realtime Logs[revalidate] Updated routes: shared-sections