Hey, guys. 1
Well done. 2
You've made it through the first half of the course. 3
In this second half, we're going to be talking about the backend side of web development and learning 4
and writing 5
all the code that takes care of all the behind the scenes functionality. 6
So recently, I came across a tweet by Paul Graham, who's the founder of Y Combinator, and something 7
he said really stuck out to me. 8
If you think about it like this, the amount of equity you get in a startup decreases exponentially 9
as your employee number increases. 10
So if you wanted to get rich from a startup, you have to be there early. 11
And in a typical tech startup, the thing that matters early on is programming. 12
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. 13
Instead, you're probably going to be a programmer who's really good at building stuff. 14
So what does that mean, somebody who's really good at building stuff? 15
Well, I took a look at the Y Combinator job board, which advertises jobs for the Y Combinator startups. 16
And this is just the list that came up. 17
And if you look at it, all of them pretty much want Full Stack. 18
Full Stack. 19
Full Stack 20
Web Developers. 21
What exactly is a Full-Stack Web Developer? 22
Well, it's the combination of knowing about how to work with the frontend, 23
so the client-facing side and also how to work with the backend, which is the side that's invisible 24
to the user, but contains all the logic that makes a web application work. 25
And this is the part that we're going to be learning about in the coming lessons. 26
Now, I love this cartoon that describes exactly what is the difference between the frontend and the 27
backend. 28
Notice that here is our user and he's looking at this beautiful mermaid, and everything the user can 29
see is a part of the frontend. 30
It's the font, it's the colors, it's the typography, it's the buttons, the forms, everything that 31
the user can see, or hear, or interact with, is a part of the front end of the website. 32
Now, what about this dragon at the back? 33
Well, because the back end is the part the user will never see and never interact with. 34
Sometimes it can get a little bit monster like, but it doesn't have to. 35
And we're going to learn all the things that's going to make our frontend as great as our backend. 36
But essentially the backend is the part the user never gets to interact with, and never gets to touch 37
or see. 38
So what exactly is the backend? 39
Don't worry, it's not anything rude. 40
It consists of three main components. 41
It's the Server, which is basically just a computer, the Application, which is all the logic that enables 42
the web app to function, 43
and finally, a Database where you can store and retrieve user data. 44
Now let's look at each of these in a little bit more detail. 45
As I mentioned before, a Server is just a computer, and a server for a live website should be on 24/7 46
so that it can listen for incoming requests from browsers from all over the world. 47
Traditionally, servers are made and optimized for this particular purpose, but at the end of the day, 48
any computer that is connected to the network can act as a server. 49
And in fact, when we're going to be building our websites locally, we're going to be using something 50
called localhost, which means we're going to be using our own computer as the server in order to serve 51
up the websites that we create. 52
And even though it's not on 24/7, or maybe you keep your computer on 24/7, it doesn't 53
matter because we only need it to be on and connected when we're testing it. 54
The second aspect of the backend is the Application, and the application is basically Logic that runs 55
on that computer, the server. 56
And this logic determines how you want to respond to the requests from the browser. 57
Depending on what that request is, let's say a user clicked on a button and that request came through 58
the server to the application, 59
well, the application knows that that particular button should then return a particular HTML page. 60
So then it sends that HTML page back to the browser and the user gets a look at a new web page. 61
Sometimes an application can also respond with different things other than HTML. 62
So it could send back Data or it could send back just a Status Code. 63
And you've probably all been on websites where you've seen the status code that is a "404", 64
and this is a code that the application on a server sent back because it's trying to tell the browser 65
that that particular request you sent is invalid. 66
And what that means is the application does not know how to respond to that particular request, the 67
browser made. 68
So maybe you try to go to a weird URL that doesn't exist, or you try to click on something that's broken. 69
But either way, when the application doesn't know what to do with the request the browser is sending 70
over, it will send back an invalid, which is a 404 status code and then usually your website will 71
just show the user, "Oops, I think you did something wrong." 72
The final aspect of the backend is the Database. 73
And this is not a requirement of web applications, but usually as your web app gets more complex and 74
larger, then it's going to need to start to store user data and that is what databases are for. 75
So when we store the data onto a hard drive, it's kind of like saving your word document, right? 76
If suddenly the power went out and you didn't save your work, then you will probably lose it. 77
But if you hit Save, even if the power goes out the next time you log on, you'll still be able to 78
see your work. 79
And this happens exactly the same way on a server. 80
If that computer lost power and you didn't have any sort of database, then all of that data will get 81
completely wiped unless we have a way to Persist 82
the information. 83
So you can view the database as a form of permanent storage for your web application. 84
Now, I keep talking about this idea of a Web Application, and the reason for that is because so far 85
what we've been building, websites that only have a front end, they are essentially web pages, they 86
are bits of HTML that gets requested from the browser to our server, and the server then returns that 87
HTML file which gets rendered on the browser. 88
So it could include the HTML, the CSS and the JavaScript. 89
And this is why we've been able to use GitHub pages to serve these static web pages because all we needed 90
to do was to store these files somewhere and when the user requests it by going to a particular URL, 91
then the server, which in our case was GitHub pages, then returns these files back to the browser 92
and gets rendered for the user to see. 93
Nothing very complex there. 94
But when we're talking about a Web Application or a Web App, then in this case it should be able to 95
do something beyond just allowing users to view web pages. 96
Let's think about a really, really simple type of web application functionality, and that is simply 97
just allowing users to log in. 98
Let's say the user goes to our website, our web app, and enters their email and their password because 99
they're trying to log in to our website. 100
Now, these two pieces of information are passed to our server in a request because our server is on 101
and is listening for requests, it's able to find the application that knows how to handle the login. 102
So maybe it'll be like a login.js file. 103
In this file there will be some logic that knows how to log a user in and that logic is usually pretty 104
simple. 105
We could look inside our database, look for a particular email and get hold of the password for that 106
email, and then we can compare that password that's in the database for the user's email against the 107
password that they sent us from the frontend. 108
And if those two pieces of data match, then we can send back via the server a response 109
in the form of, say, the Home page. 110
Right? 111
So home.html maybe. 112
And if for some reason it didn't match, then maybe our response would be to send them back to the login 113
page and get them to try again with an error code. 114
If you think about this whole flow of our web application, things are a little bit more complex, 115
and the reason why it is more complex is because we now have a web application with logic and a front 116
and a backend. 117
The frontend is everything the user sees, 118
the backend is all of the things that the Server, the Application and the Database does in order for 119
our website to have more complex functionality. 120
If that's all a little bit abstract and difficult to imagine, then you can think of a restaurant as 121
a really good analogy for this process of frontend and backend. 122
If we divide up a restaurant into a frontend, which is the actual restaurant that the user or the 123
client gets to see, and then we have all of the rest over here as the backend, 124
then we can start thinking about what happens when we order at a restaurant. 125
Firstly, you enter the restaurant. 126
Here you are a little stick figure, looking beautiful as always, and you say to the waiter, "Hey, 127
I want something." 128
So you take a look at the menu, which essentially is all of the functionality that this particular 129
web app has. 130
And you can also think of this as just all the different interactions on the website, buttons, or forms, 131
and you decide to click on a particular button, let's say, right? 132
So you click on this button on a website or in the case of our restaurant, you tell the waiter your 133
order from the menu, and then what the waiter is going to do is he's going to traverse from the 134
frontend to the backend. 135
And this is what happens when your browser sends that request to your server. 136
The server is effectively the same as the kitchen in the restaurant. 137
It's open 24/7, 138
well, certain restaurants are anyways, but in this case it's listening for the requests 139
that's coming from our waiter, from the frontend, from the restaurant and in the server there are 140
applications, which is basically our chefs, 141
and what our chefs are able to do is they have lots of recipes. 142
They know exactly how to respond to different requests from the client. 143
So let's say in this case, the client wanted some pancakes. 144
Well, the application, our chef, knows how to make a pancake. 145
It has the pancake recipe. 146
It checks the recipe it sees, 147
"Oh, we need some data from our database." 148
If we imagine the pantry as the database of the restaurant, then what the chef or the application is 149
going to do is going to request those ingredients or those pieces of data to process it or work with 150
it somehow 151
and then at the end, it's going to send back a response to the frontend. 152
So in this case, we got some pancakes that were made in the kitchen and sent into the front of house, 153
which is the restaurant, and in our server that could be some HTML, CSS and JavaScript files that 154
got created or retrieved and sent over to the frontend. 155
Now, if you wanted more food or a different item, then you can again, ask the waiter to make another 156
request to your server. 157
And this cycle of response and request between the frontend and the backend is essentially how most 158
web apps work. 159
So the next time when you're thinking about how a Full-Stack Web Application works, you can think about 160
the client who's a person at a restaurant who is ordering food, and that request gets relayed to the 161
kitchen, which is the server-side. 162
And in the server there's an application which is similar to the kitchen that prepares the order and 163
working with the data in the pantry of the kitchen, 164
and once all of that logic is processed, the 165
food, 166
the actual thing that the user should see is then sent back to the client-side where the response is 167
the food on the actual plate. 168
In the next lesson, let's learn more about the actual tools and technologies that are used to build 169
the backend of web applications. 170
So for all of that and more, I'll see you on the next lesson.