Instructor: In the last section,
we spoke about the differences between cookies and tokens,
and we ended up saying that
we were going to base our authentication
on a token-based authentication system.
And I also said that that was kind of the way
that the industry is trending
because it's easier to just build
large and scalable applications.
Let's take a look at a diagram
at the type of infrastructure,
the type of server structure
that we're going to use in our application
to demonstrate this in process,
in practice, whatever.
Anyways, here's our diagram.
So let's imagine for a second
that a user visits our website,
which we're going to call our-app.com.
When a user visits our-app.com,
they expect to be given a index.html page
and a bundle.js file.
Essentially everything that's required for application.
We're going to say that we're gonna host this
on something called a content server,
whose only job is to serve index.html and bundle.js.
It does absolutely nothing else.
No business logic, no concept of users,
no authentication, nothing like that.
If anyone makes a request to the server,
they're always gonna get index.html and bundle.js.
What that means is that we can make this content server
very simple and very stupid.
We can also spin it up on the fly
in many different geographic locations if we so required.
So this is a server that is easily redistributed,
very lightweight, doesn't require a lot of resources.
If we visited our-app.com
and we were served our application
from this content server of sorts,
but we had our APIs listed on a different domain,
so let's say, that our APIs listed somewhere else
on a different domain,
we would not be able to access this API server with cookies
because it is on a different domain
and that's why we would be using tokens in this case.
Tokens can easily go cross domain.
This is also extremely relevant if we were say,
building a mobile app to serve along with our API server.
Maybe our web app and the mobile app
need to use the same API,
and so it makes a lot more sense to have
a very single location to serve our API
that is not necessarily tied 100%
to the web application or to the mobile application.
Instead, it's its own very functional,
very separate, very discreet unit,
the API server.
It also makes it a lot easier
to update our application on the fly in the future.
Let's say that we've got a team of front-end developers
and a team of back-end developers on the server.
The front-end developers might be chugging away all the time
and developing one feature per day.
And so whenever they need to update their content,
they just push a new bundle.js and new index.html
to this content server right here,
and poof,
any user who now revisits the page,
immediately gets the new index.html and bundle.js,
frontend totally updated.
That is completely separate from the backend engineers
who might not want to have
a bunch of downtime caused by updates
for the content server.
So by making these separate services,
we get a much more granular control
over making updates to our application in the future.
Scaling with this approach is also a lot easier.
Let's look at another diagram for that.
Let's say that our content server,
maybe we only need to serve,
you know, our web app to say 1,000 people.
Maybe only 1,000 people are using our web app at any time.
But maybe we've got some mobile app
over here off to the side that's not pictured,
where we have 5 million users
and we need tremendous demand on the API
for serving those mobile app users.
If we follow this kind of approach,
where we have a separate content server to serve the web app
and a separate API server for any API requests,
we can scale out the API to be tremendously large.
You know, something that can actually serve
all those millions or thousands
and tens of thousands of different users for the mobile app.
And it would be all localized on our API.
And it wouldn't need to touch our frontend
of our React and Redux app at all.
No considerations there, completely separate applications.
So this is the approach that we're gonna take
for the application we're going to build.
In this section, this coming section,
as we're working on a server,
we're going to be exclusively working on this API server.
So we're going to build the API server,
we're gonna make sure that authentication is working
through and through,
and once we're done with it,
then we'll go and develop our mobile application,
or excuse me, our web application using React and Redux.
So in the coming sections, 100% Node and Express.
So with that in mind,
let's start writing some actual code in the next section.