All language subtitles for 003 Dev vs Production Server_en

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.