We learnt how we can use
Incremental Static Regeneration
to re-fetch the data
at regular intervals,
like 30 seconds,
as specified by the "revalidate" option.
But Next.js also offers a way to
re-fetch the data on the server side
every time the page is loaded.
Let's look at this option,
starting from our "index-1a" page,
that I'm going to duplicate
to create another option called "1c".
So "Option 1c" is still about
fetching data on the server side.
But this time instead of "getStaticProps"
we'll use a function called "getServerSideProps".
The way this works is that
we can literally just rename "getStaticProps"
to "getServerSideProps", and that's it.
And "getServerSideProps" will be called
every time this page is requested.
Let's see this in action
by re-building our app again.
Just like ISR, this feature
only makes a difference in production mode.
Now, if we look at the build output
you can see that "index-1c" has
a lambda symbol next to it.
We haven't seen this before.
The lambda means that this page
server-side renders at runtime,
and uses "getServerSideProps".
There's actually another name for this function,
that is "getInitialProps",
but that's just an old name,
"getServerSideProps" is the recommended one.
The interesting part is that
it is server-side rendered but at runtime,
as opposed to rendered as static HTML
like the other page types we've seen so far.
Now, let's try and run the application
to see how it works in action.
We know that when we load
a statically generated page, like "index-1a"
the server simply returns
the HTML page generated during the build,
which means we don't see any new messages
printed in the server logs.
But if we load our new "1c" page,
in this case you can see that
"getServerSideProps" was called
as soon as we made the request.
And if we reload this page,
this will trigger another call
to "getServerSideProps".
This also means that
if we change something in our product data
like if we set this title
back to its original value,
and we go and reload this page
it immediately shows the latest title,
because it re-fetches the data at every request.
So that's the advantage of "getServerSideProps":
it always displays the latest content,
just like when fetching data on the client side
but the server still returns pre-rendered HTML
to the browser.
The downside compared to "getStaticProps"
is that the page is generated at runtime,
so the response will be slower,
and also we're making a request to the CMS
every time a user loads a page
which means we're sending potentially
lots and lots of requests to the backend,
which can make our app less scalable.
That's why whenever possible
I recommend using "getStaticProps"
rather than "getServerSideProps",
and if you want the data to be updated
do that using Incremental Static Regeneration,
so you'll make at most one request to backend
every whatever period you configure as "revalidate".
Now, the other interesting things to note is that
"getServerSideProps" is effectively
the same behaviour we always get
when running in "dev" mode.
With "npm run dev" whenever we load the "1c" page
we'll trigger a new call
to "getServerSideProps",
just like when running in production mode.
But in dev mode the same happens
even if we load a page that uses "getStaticProps",
like "index-1a".
Every time we reload this page
"getStaticProps" will be called again.
And in fact the same thing will happen
if we load "index-1b",
that's the one that uses
Incremental Static Regeneration.
So effectively in development mode
there is no difference between "getServerSideProps",
and "getStaticProps",
with or without "revalidate" option.
In "dev" mode they all work in the same way
as "getServerSideProps".
That makes sense because in dev mode
we always want to re-generate the whole page
to make sure our latest code works.
But keep in mind that
to test things like static regeneration
you need to run the app in production mode.