In this video we'll talk about the difference
between running our app in the dev server,
and running it in production.
We've already seen that, when running
a local server with "next dev",
every time we request a page in the browser
it will be re-rendered by the server.
The dev server is designed to
help us develop our app.
While we're working on the code
we want any changes we make to be visible
in the browser as soon as possible.
That's why the dev server regenerates
the page each time,
based on the latest code in our project.
But that's not how things work in production.
Let's see how to build and run
our app for production.
I'll stop the dev server.
And, if we look at the help
for the "next" tool again,
it provides a "build" command,
that we can use to create an
optimized production build.
And also a "start" command,
that lets us run the Next.js
server in production mode.
So, let's add some more scripts
to our "package.json".
We want "build", to run "next build".
And then a "start" script,
that will execute "next start".
If we save, we can then run those
scripts in the terminal.
Let me maximize this panel, so
we can see the full output.
First, we want to execute "npm run build",
that will generate an "optimized
production build".
As you can see, it's pretty quick.
The build command prints a useful summary.
You can see that it generated a route
for each page in our project:
the root path, "/about", "/reviews", and so on.
And, if you notice, there is a little
circle before each path.
At the bottom, it explains that the
circle means it's a static page.
One that's "automatically
rendered as static HTML".
So, the build step generated static HTML
files for each one of our pages.
In fact, you can see that,
during the build process
it also rendered our HomePage component.
It will have rendered all our components,
both the pages and the layout.
It's just that we only log
a message in the HomePage.
But that's how it generates the static HTML.
Now, all these pages have been generated
inside the ".next" folder.
If we look under "server", and then "app",
you can see that there are HTML
files for all our pages:
"about.html", "index.html", and so on.
Let's take a quick look at "index.html".
I'll format the document,
it was generated as a single
line to minimize its size.
Anyway, you can see here that this HTML contains
the elements rendered from our HomePage component,
and also from the RootLayout component.
So all our React components have been pre-rendered
to HTML during the build process.
This way the Next.js server can simply
return that index.html file,
whenever a client requests the home page.
Don't worry about the exact structure
of this ".next" folder.
It's all done automatically by the "next" command.
Now, let's see how to run our app.
We can simply type "npm start",
and this will launch the Next.js server.
By default it runs on localhost on port 3000,
just like the dev server.
But with "next start" it's running
in production mode.
Let's open the home page,
and I'll do a hard-reload, just to make
sure the browser doesn't use the cache.
The home page of course looks
the same as in dev mode.
However, if we reload the page,
we don't see any messages printed
to the server logs.
So, the HomePage doesn't get
re-rendered every time,
like when running it in the dev server.
As we've seen, the build step generated a static
HTML file inside the ".next" folder,
so the production server will simply
return that existing file,
which is faster than regenerating
the page every time.
The production server is optimized for speed.
Let's take a look at the network requests as well.
When we load the page from the production server,
it should be faster than with the dev server,
although this is a very simple page, and
we're running everything locally,
so it's not a particularly meaningful test.
Now, since we're talking about
running our app in production,
there are actually a few different ways
we can deploy a Next.js project.
And it's better if you know from the start
how you plan to make your application
available to your users.
What we've done in this video is run
our app in the Node.js server.
We did an "npm run build" first,
and then "npm start" to launch the server,
using our local Node.js installation.
You could follow exactly the same
process on a server machine,
rather than on your local machine,
you could then allow HTTP access to that server,
and you'll have a website that people can visit.
But there are easier solutions as well.
Next.js is developed by a company called Vercel,
that offers a cloud platform where,
among other things,
you can deploy your Next.js application.
It's not the only platform that provides
this kind of functionality.
You can do something similar with AWS Amplify,
Netlify, and so on.
The advantage of these platforms is that
you don't need to set up and maintain
the servers yourself.
If you want the greatest flexibility
in terms of where you can deploy your website,
then you can do a static HTML export.
This lets you build your project into a folder
containing only static HTML, JavaScript,
and other files,
and you can then upload that
folder to any web server.
But not all of the Next.js features are compatible
with exporting your app as static HTML.
As we'll see later in the course,
some features require a server
running with Node.js.
In the first part of this course
we'll only use static pages
thatÂ are compatible with doing
a static HTML export.
I'll tell you when we start using features
that require a Node.js runtime.
In fact, once our app is a bit more complete,
we'll also see how to deploy it to Vercel,
or as a static website.
The most important takeaway
from this video is that
when we run our app in dev mode
some things work a bit differently
from how they work in production.
In particular, the dev server will re-render
our pages every time we request them,
but that's not the case in production,
at least with static pages.