CMS setup - Compiling static pages
Answered
Chalcid wasp posted this in #help-forum
Chalcid waspOP
This a cross post from a Stack Overflow question I posted this morning: https://stackoverflow.com/questions/77171097/nextjs-13-app-router-cms-setup-compiling-static-pages
Setup: Nextjs 13 using App router. Aim: A path that will fetch blog pages from the api and list them out. Problem: I can't compile my app for production because nextjs tries to call the headless CMS api which doesn't exist yet (first deploy) or could be out of sync due to code/db changes (subsequent deploys).
I am using a headless CMS to host a blog and some other pages. The majority of my site is set up to work with a fallback path that catches all (as an editor could publish a page on any url, nextjs doesn't know what page type or data to show at build time).
I thought I might add a hardcoded path for /blog/. This will have lots of static content and then list out articles fetched from the CMS.
Relevant component:
My aim is for nextjs to take advantage of knowing that /blog/ exists to do things like create an optimised entry point bundle for /blog/.
As the CMS is not available at build time (and you couldn't just build in a static list of links for a blog where editors are free to publish content anyway) I'd like nextjs to precompile to suspense state and still fill in the fetch results dynamically when requests come in.
What happens is the build fails because nextjs tries to fetch the articles.
Is there anyway to achieve what I want or should I just use the fallback path for my entire site and render everything dynamically with no built-in static help? Can I tell next to compile/generate a path as far as the Suspense UI but not through to the actual fetch?
Thanks.
Setup: Nextjs 13 using App router. Aim: A path that will fetch blog pages from the api and list them out. Problem: I can't compile my app for production because nextjs tries to call the headless CMS api which doesn't exist yet (first deploy) or could be out of sync due to code/db changes (subsequent deploys).
I am using a headless CMS to host a blog and some other pages. The majority of my site is set up to work with a fallback path that catches all (as an editor could publish a page on any url, nextjs doesn't know what page type or data to show at build time).
I thought I might add a hardcoded path for /blog/. This will have lots of static content and then list out articles fetched from the CMS.
Relevant component:
const _ArticleList = async () => {
articles = await fetchArticles(..., { cache: "no-store" })
return (
// Article list UI
)
}
export const ArticleList = async () => {
return (
<Suspense fallback={<LoadingUI />}>
<_ArticleList />
</Suspense>
)
}My aim is for nextjs to take advantage of knowing that /blog/ exists to do things like create an optimised entry point bundle for /blog/.
As the CMS is not available at build time (and you couldn't just build in a static list of links for a blog where editors are free to publish content anyway) I'd like nextjs to precompile to suspense state and still fill in the fetch results dynamically when requests come in.
What happens is the build fails because nextjs tries to fetch the articles.
Is there anyway to achieve what I want or should I just use the fallback path for my entire site and render everything dynamically with no built-in static help? Can I tell next to compile/generate a path as far as the Suspense UI but not through to the actual fetch?
Thanks.
Answered by fuma
Static pages must be built in the build time, hence your CMS has to be available at build time. Otherwise, you may consider turning it into ISR.
Catch the error and return a fallback page if CMS isn't available yet. Expose an API endpoint that revalidates all the pages, and calls it when CMS is available.
However, this solution is going to introduce a few minutes of downtime before your CMS is actually available. You should avoid this anyway. Headless CMS shouldn't be down. There must be something you've done wrong, it is a terrible idea tbh.
Catch the error and return a fallback page if CMS isn't available yet. Expose an API endpoint that revalidates all the pages, and calls it when CMS is available.
However, this solution is going to introduce a few minutes of downtime before your CMS is actually available. You should avoid this anyway. Headless CMS shouldn't be down. There must be something you've done wrong, it is a terrible idea tbh.
3 Replies
Static pages must be built in the build time, hence your CMS has to be available at build time. Otherwise, you may consider turning it into ISR.
Catch the error and return a fallback page if CMS isn't available yet. Expose an API endpoint that revalidates all the pages, and calls it when CMS is available.
However, this solution is going to introduce a few minutes of downtime before your CMS is actually available. You should avoid this anyway. Headless CMS shouldn't be down. There must be something you've done wrong, it is a terrible idea tbh.
Catch the error and return a fallback page if CMS isn't available yet. Expose an API endpoint that revalidates all the pages, and calls it when CMS is available.
However, this solution is going to introduce a few minutes of downtime before your CMS is actually available. You should avoid this anyway. Headless CMS shouldn't be down. There must be something you've done wrong, it is a terrible idea tbh.
Answer
Chalcid waspOP
Thanks for your reply. I guess I'm thinking of nextjs + the CMS as a one combined app whereas by the sounds of your reply I should be treating them separately. Get the CMS up and running and then deploy nextjs.
Yeah, that's much better.
Similar to Sanity (which is my favourite headless CMS), their database is hosted on the cloud while the editor is a part of website.
As a result, I can still query documents at build time when having the editor in the app itself.
Similar to Sanity (which is my favourite headless CMS), their database is hosted on the cloud while the editor is a part of website.
As a result, I can still query documents at build time when having the editor in the app itself.