Now before we get our hands dirty,
let's understand deployment in theory.
And let's start with the different deployment options
Next.js gives you.
Because it turns out,
that you have two totally different ways of building
and deploying your Next.js app.
The first and most common option is the Standard Build,
as I like to call it.
But we also can actually do a Full Static Build
and deploy our site as a full static website.
Now, let me explain what these two options mean.
You do a standard build by running the next build command
or in your project, where you have a package.json file,
this build script which runs next build under the hood.
We saw that command in action earlier
in the course already,
when we talked about static page generation and so on.
When running this command,
Next.js produces a optimized production build,
optimized production bundles for your application
and very important, it spits out a service-side application.
The result of running next build
is an output that requires a NodeJS server to run it.
So you can't take the output of next build
and put it onto some static host.
You would be able to do that for a standard React app,
a non Next.js app, but because Next.js
has these built-in service-side capabilities,
like pre-rendering pages on the fly, on the server,
revalidating pages, API routes.
Because it has these service-side features,
it needs a NodeJS server to run that code,
should make sense.
Now don't get me wrong,
pages will still be pre-rendered
during the build process if possible.
So if you have pages with get static props
or with no data at all,
those pages will still be prebuilt when you run next build.
But you still have the NodeJS server, as I just explained,
for your API routes,
which can and should only run on the server,
for server-side pages
that use the get server-side props function
and for page revalidations,
which you might wanna perform
on your statically rendered pages.
You also need a NodeJS server for dynamic pages
with getStaticPaths if you have fallback set to true
or blocking, because then some of the pages will be created
on the fly when requests are reaching the server.
And you need a server that is able to do that
for that as well.
So that is why you need a NodeJS server
for running the output next build gives you.
And that has implications.
It means that when you deploy that output,
you need to deploy it onto a host
that is able to run NodeJS.
And we're going to see that later in this course section.
Now when deploying a site, an application
you also typically need to redeploy from time to time.
And when doing a standard build,
you need to redeploy whenever your code changes, of course
because you want your latest code to be
in effect in production,
but you will also need to redeploy if your content changed
and you need to re-render some of your pages
because you're not revalidating them on the server
because you haven't added that revalidate setting
in get static props.
Then if you have such pages
as we, for example have them in our blog application here
in our blog site, there I have pages
where I pre-rendered the pages with some data
and I don't revalidate.
If you have such pages, which is no problem,
but if you have such pages,
you will also need to redeploy
whenever the contents that influences those pages
or that impacts those pages changed.
Now that's the standard build,
which you get with next build.
For some projects,
the full static build is a good option though.
You get that by running next export, another command.
We could run this in our project
by adding a script for that.
Here in package.json,
we could add a export script
or a however you wanna call it,
where we then run next export.
Now next export does something totally different
than next build.
It also produces an optimized production version
of your application
but it produces a 100% static application,
which means only HTML, CSS and JavaScript,
no server-side code
and therefore for hosting such a website,
you don't need a NodeJS server.
Which makes hosting easier because you don't need to worry
about scaling and so on, so much
because there are plenty of static hosts out there
which scale dynamically and are very cost-effective.
So having a static app,
which doesn't require a NodeJS server, isn't too bad.
It can definitely make deployment a bit easier
but next export isn't always an option.
Since it spits out a 100% steady gap,
there are certain things, certain next features
which you just can't use in such a application.
For example, you can't use next export
if your site relies on API routes,
on service-side pages with get service-side props,
on page revalidations,
or if you have static paths with fallback set to true
or blocking.
All those things require a code to execute on demand,
for incoming requests on the server.
And therefore it's difficult, if you have no server.
So next export only works
if you have a page which doesn't need any service-side code.
Now, when building a page with next export,
you have to be aware of the fact that
that means that you need to redeploy your application
whenever your code changes
but also whenever any content changes,
since you can't use page revalidations
and fallbacks and so on,
you need to redeploy whenever any content changed
because you'll need to export your application again.
You need to rebuild all the pages again.
Again, that might not be a disadvantage.
That can be perfectly fine for a simple blog, for example.
There you add a new blog post every week,
you do a redeployment every week.
Not too difficult, just one step,
and then next export can be a great option.
In the blog application we built in the last course section,
next export wouldn't be our option at the moment
because we're using API routes, for example
and because we're also using revalidations in some pages
and these are all features that require a NodeJS server,
since these are all tasks
which will execute after deployment
on the server for incoming requests.
Nonetheless, these are your two options
and we are going to see
both options in action in this course section.