pages/stuff.ts
export function getServerSideProps(context) {
const userId = getUserIdOrNull(context);
return {props: { somethingComplicated: getSomethingComplicated(!!userId) }};
}
export default Home({somethingComplicated}) {
return <div>{somethingComplicated}</div>
}
How do you cache this page?!
Ideally I'd like to cache the page <Home {...{somethingComplicated}}/> based on the different contexts.
Possible but unsatisfying solutions:
Cache the calculation of somethingComplicated. Unsatisfying because Home would need to be recalculated every time and cannot be cached by cloudflare.
Load somethingComplicated dynamically on the client from an api. Unsatisfying because the lack of server side rendering is a worse user experience.
Route for logged in users and logged out users to different routes. Unsatisfying because user visible urls will be different and the redirects get complicated.
I can't seem to find a satisfying solution. Maybe it's not possible? Anyways, thanks in advance for your time.
By default, Next.js pre-renders every page. This means that Next.js
generates HTML for each page in advance, instead of having it all done
by client-side JavaScript. Pre-rendering can result in better
performance and SEO.
Each generated HTML is associated with minimal JavaScript code
necessary for that page. When a page is loaded by the browser, its
JavaScript code runs and makes the page fully interactive. (This
process is called hydration.)
Two forms of Pre-rendering:
Next.js has two forms of pre-rendering:
Static Generation and Server-side Rendering. The difference is in when
it generates the HTML for a page.
Static Generation (Recommended): The HTML is generated at build time
and will be reused on each request. Server-side Rendering: The HTML is
generated on each request.
you can read more
If you are using getServerSideProps that means every time a user visits that page, you want to fetch fresh data and serve it to the user. If your serverside is doing heavy calculation or hitting database disk you could implement caching layer between application server and db or other servers. You could use redis
I am using https://github.com/i18next/next-i18next and rather than hardcoding the files, I want to use HygraphCMS (formerly GraphCMS) to provide those strings. What's the best way to approach this?
If I wait for an async request, it'll slow things down. Thanks in advance!
I pumped into similar issue before, what I did was I created a script that runs before the dev and build commands, something like:
// ...
"scripts": {
// ....
"trans": "node ./scripts/get-i18n.js",
"dev":"npm run trans && next dev",
"build":"npm run trans && next build"
}
// ...
And you write a script get-i18n.js to fetch you translations from the CMS and save them in the directory you chosed in the i18n setup.
The downside of this approach that if the translation changed in the CMS you would need to restart the server everytime, or run the script manually in another shell to make the fetch and update the strings.
The best solution here would depend on how you have the rest of the Next.js project set up and how much you want to avoid an async request. I've described two approaches I would consider below. Both examples assume you're using Next.js and hosting on Vercel, but it should be possible and similar through other platforms.
1. Build script to store locally (without async request)
Start by writing a script to fetch all the translations and store them locally in the project (just as Aldabil21 said).
After that, you can create a deploy webhook and call it from your CMS whenever a change is made; this will ensure that the translations are always kept up-to-date. An issue with this could be that the build runs too often, so you may want to add some conditions here to prevent that, such as only calling the webhook from the CMS when the translations content changes.
2. Using incremental static regeneration (with async request)
Of course, if you're using incremental static regeneration, you might reconsider fetching the translations using getStaticProps as the request is not made for each visitor.
The result of the request to the CMS's translation collection would be cached on Vercel's Edge network and then shared amongst each visitor, so only the first request after the cache has expired will trigger the full request. The maximum age for the caching of static files is 31 days, so this delay when requesting fresh data could be infrequent enough to be acceptable. Note that you have to enable this manually by setting the revalidate prop in the return object of getStaticProps.
You could even mitigate this request further (depending on your project setup) by querying only for the language that is currently used, and querying a new language client-side only when it is requested by the visitor (or possibly once the page is idle or the language switcher is opened). If you have many languages, this reduction will reduce the download time substantially.
If you do go the getStaticProps route and are using Next.js >12.2.0 then you could also create a CMS webhook to call the on-demand revalidation endpoint whenever a page is updated, which will cause the fresh translations to be stored in cache before a user gets a chance to request it, removing the delay for all users. Or you could use the webhook in the same way as mentioned in 1 and trigger a new build (with the new translations) every time the translation collection is updated.
Hello I am new to the Next.js, I know that in getStaticProps Next.js will pre-render this page at build time and in getServerSideProps Next.js will pre-render this page on each request using the data returned by getServerSideProps
But i want a example of when to use getStaticProps and getServerSideProps for website
With getServerSideProps (SSR) data is fetched at request time, so your page will have a higher Time to first byte (TTFB), but will always pre-render pages with fresh data.(can be use for dynamic content/it allows you to improve your SEO as in this method the data is rendered before it reaches the client.)
With Static Generation (SSG) The HTML is generated at build time and will be reused on each request, TTFB is slower and the page is usually faster, but you need to rebuild your app every time the data is updated (can be acceptable for a blog, but not for an e-commerce).
With Incremental Static Regeneration (ISG) static content can also be dynamic, the page will be rebuilt in the background with an interval-based HTTP request. You can specify how often pages are updated with a revalidate key inside getStaticProps, this works great with fallback : true and allows you to have (almost) always updated content.
When to use:
getStaticProps: Any data that changes infrequently, particularly from a CMS. (Must be used with getStaticPaths if there's a dynamic route).
revalidate: An easy add-on to getStaticProps if the data might change, and we're OK serving a cached version.
getServerSideProps: Primarily useful with data that must be fetched on the server that changes frequently or depends on user authentication.When we want to fetch data that relates to the user's cookies/activity and is consequently not possible to cache.
SSR doesn’t cache any data. It fetches new data on every request which often results in a slower performance.
SSR should be used when we don't know what the user wants, otherwise we use SSG or ISG in case of dynamic content.
Here is some examples to what to use in each case:
getServerSideProps (SSR):
a JWT after a successful login
GeoLocation of the user (the content on the page may depend on the geo location of the client, so it's very useful to use SSR in this case)
Static Generation (SSG):
wiki page
Privacy-policy page
a blog if data is changed very often
Website settings (Colors, themes, ...)
Incremental Static Regeneration (ISG):
e-commerce store
news website
The data revalidation will happen on the server and will benefit all
visitors.
Client-side rendering (CSR):
Content that is only accessible for authenticated users (dashboards)
The data revalidation will happen on the client and will only benefit that single user.
SWR/ReactQuery + Incremental Static Regeneration (SWR + ISG):
this approach is also a very good one if you want instantly updated data for the current user and statically regenerated for the next visitors.
NextJs v12.2.0 introduced the "On-Demand Revalidation" which is very powerful and useful.Let's say you have a news website, using the old Incremental Static Regeneration is not the best solution, imagine we set the revalidation to 1 hour, that means the newest urgent news that we just published will not be published on the website until one hour, too bad :( and here where On-Demand Revalidation comes to play. When you publish your new article you will call the "revalidate()" method using an API and the articles page will be regenrated without waiting the revalidation time.
As of Next.js 10, the getStaticPaths function returns an object that must contain the very important fallback key as documented at: https://nextjs.org/docs/basic-features/data-fetching#the-fallback-key-required
While the documentation is precise, it is quite hard to digest for someone that is just beginning with Next.js, could someone try to provide a simpler or more concrete overview of those options?
How to test
First of all, when testing things out to make sure I had understood them, I was getting really confused because when you run in development mode (next dev) the behavior is quite different than when running in production mode (next build && next start), as it is much more forgiving to help you develop quickly. Notably, in development, getStaticPaths gets called on every render , so everything always gets rendered to their latest version, which is unlike production where more caching might be enabled.
The docs describe the production behavior, so to test things out, you really need to use production mode.
The next issue is that I couldn't easily find an example where you can create and update pages from inside the example itself to easily view their behavior. I finally ended up doing that at: https://github.com/cirosantilli/node-express-sequelize-nextjs-realworld-example-app while porting the awesome Realworld example project, which produces a simple multiuser blog website (mini Medium clone).
With those tools in hand, I was able to confirm what the docs say. This answer was tested at this commit which has Next.js 10.2.2.
fallback: false
This one is simple: only pages that are generated during next build (i.e. returned from the paths property of getStaticPaths) will be visible.
E.g., if a user creates a new blog page at /post/[post-id], it will not be immediately visible afterwards, and visiting that URL will lead to a 404.
That new post will only become visible if you re-run next build, and getStaticPaths returns that page under paths, which is the case for the typical use case where getStaticPaths returns all the possible [post-id].
fallback: true
With this option, Next checks if the page has been pre-rendered to HTML under .next/server/pages.
If it has not:
Next first quickly returns a dummy pre-render with empty data that had been created at build time.
In this, you are expected to tell the user that the page is loading.
You must handle that case, or else it could lead to exceptions being thrown due to missing properties.
The way to handle this is described in the docs by checking router.isFallback:
import { useRouter } from 'next/router'
function Post({ post }) {
const router = useRouter()
// If the page is not yet generated, this will be displayed
// initially until getStaticProps() finishes running
if (router.isFallback) {
return <div>Loading...</div>
}
// Render post...
if (router.isFallback) {
return <div>Loading...</div>
}
return <div>post.body</div>
}
So in this example, if we hadn't done the router.isFallback check, post would be {}, and doing post.body would throw an exception
After the actual page finishes rendering for the first time with data (the data is fetched with getStaticProps at runtime), the user's browser gets automatically updated to see it, and it stores the resulting HTML under .next/server/pages
If the page is present under .next/server/pages however, either because:
it was rendered by next build
it was rendered for the first time at runtime
Next.js just returns it, without rendering again.
Therefore, If you edit the post, it will not re-render the page cache. The outdated page will be returned at all times, because it is already present under .next/server/pages, so next does not re-render it.
You will have to re-run next build to see updated versions of the pages.
Therefore, this is not what you generally want for the multi-user blog described above. This approach is generally only suitable for websites that don't have user-generated content, e.g. an e-commerce website where you control all the content.
fallback: true: what about pages that don't exist?
If the user accesses a page that does not exist like /post/i-dont-exist, Next.js will try to render it just like any other page, because it checks that it is not in .next/server/pages thinks that it just hasn't been rendered before.
This is unlike fallback: false, where Next.js never generates new pages at runtime, and just returns a 404 direction.
In this case, your code will notice that the page does not exist when getStaticProps queries the database, and then you tell Next.js that this is a 404 with notFound: true as mentioned at: How to return a 404 Not Found page and HTTP status when an invalid parameter of a dynamic route is passed in Next.js? so Next.js renders a 404 page and caches nothing.
fallback: 'blocking'
This is quite similar to fallback: true, except that it does not return the dummy loading page when a page that hasn't been cached is hit for the first time
Instead, it just makes the browser hang, until the page is rendered for the first time.
Future requests to that page are quickly served from the cache however, just like fallback: true.
https://dev.to/tomdohnal/blocking-fallback-for-getstaticpaths-new-next-js-10-feature-1727 mentions the rationale for this, it appears to break certain rather specific features, and is generally not what you want unless you need one of those specific features.
Note that Next.js documentation explicitly states that in fallback: true, it detects crawlers (TODO how exactly? User agent or something else? Which user agents), and does not return the loading page to crawlers, which would defeat the purpose of SSR. https://nextjs.org/docs/basic-features/data-fetching#the-fallback-key-required mentions:
Note: this "fallback" version will not be served for crawlers like Google and instead will render the path in blocking mode.
so there doesn't seem to be a huge advantage for SEO purposes in using 'blocking' over true.
However, if your user is a security freak and disables JavaScript, they will only see the loading page. And are you sure the Wayback machine won't show the loading page? What about wget? Since I like such use cases, I'm tempted to just use fallback: 'blocking' everywhere.
revalidate: Incremental Static Regeneration (ISR)
When revalidate is given, new requests to a page that is in the .next/server/pages cache also make the cache be regenerated. This is called "Incremental Static Regeneration".
revalidate: n means that our server will do at most 1 re-render every n seconds. If a second request comes in before the n seconds, the previously rendered page is returned and a new re-render is not triggered. So large n means users see more outdated pages, but less server workload.
A large re validate could therefore help the server handle large traffic peaks by caching the reply.
This is what we have to use if we want website users to both publish and update their own posts:
either fallback: true or fallback: 'blocking'
together with revalidate: <integer>
revalidate does not make much sense with fallback: false.
When revalidate: <number> is given, behavior is as follows:
if the page is present under .next/server/pages, return this prerendered immediately, possibly rendered with outdated data.
At the same, also kickstart a page rebuild with the newest data.
When the rebuild is finished, the target page won't be automatically updated to the latest version. The user would have to refresh the page to see the updated version.
otherwise, if the page is not cached, do the same that true or 'blocking' would do, by either returning a dummy wait page, or blocking until it gets done, and create the cached page
After a page is built by either of the above cases (first time or not), if it gets accessed again in the next number seconds, do not trigger rebuilds. This way, if a very large number of users is visiting the website, most of the requests won't require expensive server render work: we will do at most one re-render every number seconds.
Explicit invalidation with: res.unstable_revalidate
This is currently beta, but it seems that at last they are introducing a way to explicitly invalidate pages as currently mentioned at: https://vercel.com/docs/concepts/next.js/incremental-static-regeneration
This way, instead of ugly revalidate timeouts, we will be able to just rebuild pages only when needed if we are able to detect the page becoming outdated on the server. Then we can just sever directly every time.
It will presumably be renamed to res.revalidate once it becomes stable.
This awesome development was brought to my attention by Sebastian in the comments.
SSR for a single request (i.e. ignore revalidate) so that users can see the results of their blog page edits
Edit: this use case might best resolved with the upcoming res.unstable_revalidate/res.revalidate.
If for example:
the blog author clicks submit after updating an existing post
and they got redirected to the post view page as is usual behavior, to see if everything looks OK
they first see the outdated version of the post. Then redirected this visit would trigger a rebuilt with the new data they've provided in the edit page, and only after that finishes and the user refreshes they would see the updated page.
So this behavior is also not ideal UI behavior for the editor, as the user would be left thinking:
What just happened, was my edit not registered?
for a few seconds.
This can be solved with "preview mode" which is documented at: https://nextjs.org/docs/advanced-features/preview-mode It was added in Next.js 12. Preview mode checks if come cookies are set, and if so makes getStaticProps rerun regardless of revalidate, just like getServerSideProps.
However, even preview mode does not solve this use case super nicely, because it does not invalidate/update the cache, which is a widely requested thing, related:
Next.js ISR ( Incremental Static Regeneration ), how to rebuild or update a specific page manually or dynamically before the interval/ISR time start?
How to clear/delete cache in NextJs?
so it could still happen that the user visits the page without cache and sees the outdated page. I could work around this by removing the cookies and making a an extra GET request, but this produces an useless get request and adds more complexity.
I learned about this after opening an issue about it at: https://github.com/vercel/next.js/discussions/25677 thanks to #sergioengineer for pointing it out.
Related threads:
https://github.com/vercel/next.js/discussions/11698#discussioncomment-351289
https://github.com/vercel/next.js/discussions/11552
SSR vs ISR: per user-login-based information
ISR is an optimization over SSR. However, like every optimization, it can increase the complexity of the system.
For example, suppose that users can "favorite" blog posts.
If we use ISR, it only makes much sense to pre-render a logged off page, because it only makes sense to pre-render the stuff that is common for multiple users.
Therefore, if we want to show to the user the information:
Have I starred this page yet or not?
then we have to do a second API request and then update the page state with it.
While it may sound simple, this adds considerable extra complexity to the code in my experience.
With SSR however, we could simply check the login cookies sent by the user as usual, and fully render the page perfectly customized to the current user on the server, so that no further API requests will be needed. Much simpler.
So you should really only do it if you benchmark it and it is worth it.
Here's an example of checking login cookies: https://github.com/cirosantilli/node-express-sequelize-nextjs-realworld-example-app/blob/8dff36e4bcf659fd048e13f246d50c776fff0028/back/IndexPage.ts#L23 That sample setup uses the exact same SWR tokens that are being used to make JavaScript API requests but also via cookies. We don't have to worry about XSS in that demo because we only use login on GET requests. All modifying requests like POST are done from JavaScript exclusively, and don't authenticate from cookies.
The ISR dream: infinite revalidate + explicit invalidation + CDN hooks
As of Next.js 12, ISR is wonky for such a CRUD website, what I would really want is for things to work as follows:
when the user creates a blog post, we use a post creation hook to upload the result to a CDN of choice
when a user views a blog post, it goes to the CDN directly and does not touch the server. Only if the user wants to fetch user-specific data such as "have I starred this page" does it make a small API request to the server
when a user updates a blog post, it just updates the result on the CDN of choice
This approach would really lead to ultra-fast page loads and minimal server workload Nirvana.
I think Vercel, the company behind Next.js, might such a CDN system running on their product, but I don't see how to nicely use an arbitrary CDN of choice, because I don't see such hooks. I hope I'm wrong :-)
But just the explicit invalidation + infinite revalidate would already be a great thing to have even without the CDN hook system. Edit: this might be coming with res.unstable_revalidate, see section above.
whenever we want to implement ISR or SSG techniques in dynamic routes , we are supposed to pass the paths,that we want to be statically generated at the build time,
to getStaticPaths function .Although , in some situations we might have new paths that are not returned by getStaticPaths and we have to handle this paths with fallback property that is also returned from getStaticPathsNext.js official docs
.
fallback property can accept 3 values:
false :
new paths will result in a 404 page
true :
new path will be statically generated (getStaticProps is called) - loading state is shown while generating page(via router.isFallback and showing fallback page) - page is rendered with required props after generating - new path will be cached in CDN (later requests will result in cached page) - crawler Bots may index fallback page (not good for Seo)
"blocking" :
new path will be waiting for HTML to be generated (via SSR ) - there will be no loading state(no fallback page) - new path will be cached in CDN (later requests will result in cached page)
NOTE : after Next.js 12 the fallback:true in ISR technique wont be showing fallback page to crawler Bots Read more
When creating dynamic pages in our app (for example a video app), we need to configure how next.js will fallback during the request.
If we know that the pages and our app system are quick, we are sure that our data response will be instant, we can use fallback:blocking. We do not need to show the loading state because Next.js will wait for this page to be fully pre-generated on the server before it serves that.
in fallback:false if a new page is not found 404 page will be displayed. false is used if you want to generate ALL of our dynamic paths during build time. In this case, in getStaticPath you need to fetch how many items you have in your database. Since pre-built pages are served from CDN, its look-up time is pretty quick, you are actually not fetching data, so you do not need a "loading state". You are just checking if the given URL path has a pre-generated page or not. If in the future you need to add more paths, you need to rebuild your app.
In your video app, you might have too many videos so you only prebuild the most popular video pages. If a user visits a video and its page was not pre-generated, you have to do data fetching so you need a "loading" state. Now you need to set the fallback:true. Since data fetching will take time, if you do not show a different component while loading, you might get like "Cannot read property "title" of undefined", since at that moment title of the video is not defined yet.
function Video({ videoId }) {
const router = useRouter()
// If the page is getting generated
if (router.isFallback) {
return <div>Loading...</div>
}
// then return the main component
}
I'm using NextJS getServerSideProps to get data from back-end. Back-end data that I need for current page changes each day once at 4UTC. I want to implement getStaticProps which will rebuild all pages once each day, because data on server changes only once each day.
I know about revalidate, but making revalidate with 24 hours also revalidates after each request. Also revalidating 24 hours is not exactly at 4UTC. So, how to rebuild page each day once at some specified time using getStaticProps function?
You can use On-demand Revalidation. Starting with v12.1.0, Next.js supports on-demand Incremental Static Regeneration to manually purge the Next.js cache for a specific page. This makes it easier to update your site when:
Content from your headless CMS is created or updated
Ecommerce metadata changes (price, description, category, reviews, etc.)
or for your case, at 4am everyday data is updated.
Inside getStaticProps, you do not need to specify revalidate to use on-demand revalidation. If revalidate is omitted, Next.js will use the default value of false (no revalidation) and only revalidate the page on-demand when unstable_revalidate is called.
Link for reference- https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration
Just hint, never tested ... There is a discussion about the cache purging on Vercel. In your case it should be combination of cron job and calling of purge.