All language subtitles for 002 Building NextJS Apps_ Your Options_Downloadly.ir_en

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.