So, which implications does getServerSideProps
running on the server only have for us?
The implications can be found in this context object
unlike context in getStaticProps
we don't just have access to the params
and a couple of other less important fields
instead, we get access to the full request object as well.
And also to the response which will be sent back
so that we could even manipulate this
and add extra headers if you wanted to.
To be precise we do get a couple of values
a couple of keys in this context object
and we do get access still to the params
that does not change if we have this on a dynamic page
which we don't have here
but if this would be on a dynamic page
we still would get access to params
but in addition, as mentioned, we also get access
to the request object and the response object.
Now, if you know a bit of Node.js
and especially of Express.js
this might look familiar to you.
There you also can write server side code
where you get a request object and the response object
and you can then manipulate the response object
as needed to send back an appropriate response.
Now, you don't need to worry
about sending back a response here
Next.js will do that for you
it will be derendered component
but you can manipulate the response
before it's sent back by adding extra headers, for example
by adding a cookie, for example.
In addition, you can also dive into the request object
that reached the server
and you can read incoming data from there.
For example, headers that were attached through request
and therefore cookie data that was attached to the request.
Request and response the objects we're getting here
are your official Node.js default incoming message
and response objects.
So, here I will briefly lock the request
and then also lock the response
so that we can get a closer look at them.
If I save this and I reload user profile
now this code executed again and now we see a long log here
because these are quite complex objects
with a lot of built in methods and properties.
So, you'll see there's a lot in there
and you definitely don't need to go through all of that.
But for example, you see that there are headers in there
which we could extract if we wanted to.
Now, we don't need this here
but it will become more important later
once we talk about authentication.
Now, I will quit this here and not go through all of that
but you can definitely take a close look at that.
And these again are the default node objects
for incoming messages and for responses.
And I'll link the documentation of these objects
to this lecture so that you can take a closer look
at what's in them in the official docs as well.
And getting access to this kind of data
can sometimes be important if you, again
for example, needs special header or cookie data.
And now another reason as mentioned before
for using getServerSideProps could be
that you don't need request or response specific data
that you don't need to work with request or response
but that you really wanna ensure that this function runs
for every incoming request
so that it's never static pre-generated.
Because for example you have highly dynamic data
which changes multiple times every second
and therefore, you know, that any old page
you would be serving would already be outdated.
That could be another reason for using getServiceSideProps
but as you see using it is simple.
You can still write any server side code in there.
You can still reach out to the dummy-backend.json file
as we did it before, for example
and you still return the props
for the component function at the end.
The only key difference is the kind of data
you get access to in the context
and the timing of this function.