Original subtitles

Hey, guys.

Well done.

You've made it through the first half of the course.

In this second half, we're going to be talking about the backend side of web development and learning

and writing.

All the code that takes care of all the behind the scenes functionality.

So recently, I came across a tweet by Paul Graham, who's the founder of Y Combinator, and something

he said really stuck out to me.

If you think about it like this, the amount of equity you get in a startup decreases exponentially

as your employee number increases.

So if you wanted to get rich from a startup, you have to be there early.

And in a typical tech startup, the thing that matters early on is programming.

So if you're a lawyer or an MBA or biz dev, you're probably not going to be one of the first 20 employees.

Instead, you're probably going to be a programmer who's really good at building stuff.

So what does that mean, somebody who's really good at building stuff?

Well, I took a look at the Y Combinator job board, which advertises jobs for the Y Combinator startups.

And this is just the list that came up.

And if you look at it, all of them pretty much want full stack.

Full stack.

Full stack.

Web developers.

What exactly is a full stack web developer?

Well, it's the combination of knowing about how to work with the front end.

So the client facing side and also how to work with the back end, which is the side that's invisible

to the user, but contains all the logic that makes a web application work.

And this is the part that we're going to be learning about in the coming lessons.

Now, I love this cartoon that describes exactly what is the difference between the front end and the

back end.

Notice that here is our user and he's looking at this beautiful mermaid, and everything the user can

see is a part of the front end.

It's the font, it's the colors, it's the typography, it's the buttons, the forms, Everything that

the user can see or hear or interact with is a part of the front end of the website.

Now, what about this dragon at the back?

Well, because the back end is the part the user will never see and never interact with.

Sometimes it can get a little bit monster like, but it doesn't have to.

And we're going to learn all the things that's going to make our front end as great as our back end.

But essentially the back end is the part the user never gets to interact with and never gets to touch

or see.

So what exactly is the back end?

Don't worry, it's not anything rude.

It consists of three main components.

It's the server which is basically just a computer, the application, which is all the logic that enables

the web app to function.

And finally a database where you can store and retrieve user data.

Now let's look at each of these in a little bit more detail.

As I mentioned before, a server is just a computer, and a server for a live website should be on 24

over seven so that it can listen for incoming requests from browsers from all over the world.

Traditionally, servers are made and optimized for this particular purpose, but at the end of the day,

any computer that is connected to the network can act as a server.

And in fact, when we're going to be building our websites locally, we're going to be using something

called localhost, which means we're going to be using our own computer as the server in order to serve

up the websites that we create.

And even though it's not on 24 over seven, or maybe you keep your computer on 24 over seven, it doesn't

matter because we only need it to be on and connected when we're testing it.

The second aspect of the back end is the application, and the application is basically logic that runs

on that computer, the server.

And this logic determines how you want to respond to the requests from the browser.

Depending on what that request is, let's say a user clicked on a button and that request came through

the server to the application.

Well, the application knows that that particular button should then return a particular HTML page.

So then it sends that HTML page back to the browser and the user gets a look at a new web page.

Sometimes an application can also respond with different things other than HTML.

So it could send back data or it could send back just a status code.

And you've probably all been on websites where you've seen the status code that is a 404.

And this is a code that the application on a server sent back because it's trying to tell the browser

that that particular request you sent is invalid.

And what that means is the application does not know how to respond to that particular request, the

browser made.

So maybe you try to go to a weird URL that doesn't exist, or you try to click on something that's broken.

But either way, when the application doesn't know what to do with the request the browser is sending

over, it will send back an invalid, which is a 404 status code and then usually your website will

just show the user Oops, I think you did something wrong.

The final aspect of the back end is the database.

And this is not a requirement of web applications, but usually as your web app gets more complex and

larger, then it's going to need to start to store user data and that is what databases are for.

So when we store the data onto a hard drive, it's kind of like saving your word document, right?

If suddenly the power went out and you didn't save your work, then you will probably lose it.

But if you hit save, even if the power goes out the next time you log on, you'll still be able to

see your work.

And this happens exactly the same way on a server.

If that computer lost power and you didn't have any sort of database, then all of that data will get

completely wiped Unless we have a way to persist.

The information.

So you can view the database as a form of permanent storage for your web application.

Now, I keep talking about this idea of a web application, and the reason for that is because so far

what we've been building websites that only have a front end, they are essentially web pages, they

are bits of HTML that gets requested from the browser to our server, and the server then returns that

HTML file which gets rendered on the browser.

So it could include the HTML, the CSS and the JavaScript.

And this is why we've been able to use GitHub pages to serve these static web pages because all we needed

to do was to store these files somewhere and when the user requests it by going to a particular URL,

then the server, which in our case was GitHub pages, then returns these files back to the browser

and gets rendered for the user to see.

Nothing very complex there.

But when we're talking about a web application or a web app, then in this case it should be able to

do something beyond just allowing users to view web pages.

Let's think about a really, really simple type of web application functionality, and that is simply

just allowing users to log in.

Let's say the user goes to our website, our web app, and enters their email and their password because

they're trying to log in to our website.

Now, these two pieces of information are passed to our server in a request because our server is on

and is listening for requests, it's able to find the application that knows how to handle the login.

So maybe it'll be like a login dot JS file.

In this file there will be some logic that knows how to log a user in and that logic is usually pretty

simple.

We could look inside our database, look for a particular email and get hold of the password for that

email, and then we can compare that password that's in the database for the user's email against the

password that they sent us from the front end.

And if those two pieces of data match, then we can send back via the server a response.

In the form of, say, the home page.

Right.

So home dot HTML maybe.

And if for some reason it didn't match, then maybe our response would be to send them back to the login

page and get them to try again with an error code.

If you think about this whole flow of our web application, things are a little bit more complex.

And the reason why it is more complex is because we now have a web application with logic and a front

and a back end.

The front end is everything the user sees.

The back end is all of the things that the server, the application and the database does in order for

our website to have more complex functionality.

If that's all a little bit abstract and difficult to imagine, then you can think of a restaurant as

a really good analogy for this process of front end and back end.

If we divide up a restaurant into a front end, which is the actual restaurant that the user or the

client gets to see, and then we have all of the rest over here as the back end.

Then we can start thinking about what happens when we order at a restaurant.

Firstly, you enter the restaurant.

Here you are a little stick figure, looking beautiful as always, and you say to the waiter, Hey,

I want something.

So you take a look at the menu, which essentially is all of the functionality that this particular

web app has.

And you can also think of this as just all the different interactions on the website, buttons or forms,

and you decide to click on a particular button, let's say, right?

So you click on this button on a website or in the case of our restaurant, you tell the waiter your

order from the menu, and then what the waiter is going to do is he's going to traverse from the front

end to the back end.

And this is what happens when your browser sends that request to your server.

The server is effectively the same as the kitchen in the restaurant.

It's open 24 over seven.

Well, certain restaurants are anyways, but in this case it's listening for the requests.

That's coming from our waiter, from the front end, from the restaurant and in the server there are

applications, which is basically our chefs.

And what our chefs are able to do is they have lots of recipes.

They know exactly how to respond to different requests from the client.

AT So let's say in this case, the client wanted some pancakes.

Well, the application our chef knows how to make a pancake.

It has the pancake recipe.

It checks the recipe it sees.

Oh, we need some data from our database.

If we imagine the pantry as the database of the restaurant, then what the chef or the application is

going to do is going to request those ingredients or those pieces of data to process it or work with

it somehow.

And then at the end, it's going to send back a response to the front end.

So in this case, we got some pancakes that were made in the kitchen and sent into the front of house,

which is the restaurant, and in our server that could be some HTML, CSS and JavaScript files that

got created or retrieved and sent over to the front end.

Now, if you wanted more food or a different item, then you can again ask the waiter to make another

request to your server.

And this cycle of response and request between the front end and the back end is essentially how most

web apps work.

So the next time when you're thinking about how a full stack web application works, you can think about

the client who's a person at a restaurant who is ordering food, and that request gets relayed to the

kitchen, which is the server side.

And in the server there's an application which is similar to the kitchen that prepares the order and

working with the data in the pantry of the kitchen.

And once all of that logic is processed, the.

Food.

The actual thing that the user should see is then sent back to the client side where the response is

the food on the actual plate.

In the next lesson, let's learn more about the actual tools and technologies that are used to build

the back end of web applications.

So for all of that and more, I'll see you on the next lesson.