7.1 Look at the anatomy of a web app - Video Tutorials & Practice Problems

<v ->Okay, so we're gonna start with</v> looking at the anatomy of a web app. So web apps are inherently a lot more complicated than like a single Python script or even like a desktop application that has a Gooey. You're website or web app has to be connected to the internet. So I'm gonna try to use an analogy where the internet is like roads and each web page or website on the internet is like a building that has an address. Websites have URLs that you can access. A building will have a address and that'll inform you how to get there. Once I've got to this address, I'm at the place that I want to be at. Okay, so imagine that you have a building and it's like a public services building. So let's say like the DMV in America, in the US, there's like the driver's licensing office. And so that's going to be symbolized by this building over here. And then let's say that there's another building that's associated with it that is kinda like the backend. It stores all of their data, it's got like, only certain employees can access it. And this building is what you as a public person, a public user, is gonna see and interact with. But they will be able to interact with this office, like drab office building that, you know, you could access it if you had the authorization to. So that is gonna be similar to how we have different web apps accessible on the internet. So as a user, you're gonna be able to see just what's called the front-end of the website and there's a backend, which is gonna be sitting on a computer that only some people have access to. And the front-end is gonna be able to interact and access data from the backend. But as a user, you only see this view of it. You interact with this view. So if we're making a web app, we're going to write the code for both of these and then we have to add it to the internet and have it accessible from people on the internet by connecting it to the system here. So in the backend, this is a server. There's also gonna be a database that can store data that you can't directly access as the user. Only people with the right credentials can access it. So say you're driving along and you want to go to the driver's licensing office. When you get there, you can interact with this public representative. You might be able to ask certain requests of them. So the kinds of information you can probably do are get your info, request your driver's license information. You might want to add some info so you can apply for a new driver's license. Maybe someone drove you there and now you're trying to get one. And you can also update your info, so maybe you renew your license or change your address, and you can also delete some info. So maybe you've moved countries and you need to cancel your license for now. So this translated back into websites. There's something called HTTP methods, and that stands for HyperText Transfer Protocol. You see that in the URL, HTTP. And the main HTTP methods that we care about are called GET requests, POST requests, PUT requests, and DELETE requests. So what they do is similar to what we saw in the previous slide. GET is asking for data, and this is like the front-end of your website is going to make a request to the backend, and the request can be a GET, which is asking for some data so the backend will send some data to the front-end. POST is going to say update some data. So maybe the user, like maybe someone's new and wants to create a new user account on a certain web app. You can also update some data, so like if you go into a settings page and change your email address or phone number, you can also delete some data and say oh I want to deactivate my account or delete this video that I posted. So you can ask them hey, can you please give me my license information and they can give it to you. Or you can say give me my license information and if you're not in the system, they'll be like oh sorry, 404 not found. You might have seen this from various websites. So HTTP methods also have a bunch of error codes that they might be able to give, depending on what error happened. Now looking back at this analogy, we've got the public facing building, we've got the support building, and then we've got this other thing that just stores files, it's like a big filing cabinet maybe. And that would translate into the client or the front-end, the server or the backend, and the database. What do each of these things do? Well the server stores data and you can access that data through a query language, maybe SQL if you have a relational database. And in the backend, it handles the logic. It is a go between for the front-end and the server. It is written in, we're gonna write it in Python using the Flask framework, but you can also write it in a number of other languages using their own website frameworks. Django is another popular Python framework for writing backends. And then the front-end is going to be the display that the user sees and interacts with, so it might have a forum to ask the backend to update data in a certain way. And this is gonna be written in HTML, CSS, and JavaScript. So in this lesson, we're going to learn how to write a Python server, but we're also going to look a little bit about these three languages so that we can write the front-end as well so we can write what the user sees. So the way that the data flows is from the client. So say you now had your licensing information on a website. It would be like going to this URL and then going to this endpoint that's within your website. And the data would flow like this. It would be sent to the server, the request would be sent to the server. Then the server would try to access or update the data on the database. It might get some data back, and then the server could update you and tell you whether that was successful. And if you asked for data, what that data was. But this building could have a number of different functions, so there might be the driver's license office on one side, and insurance on another side. So if you wanted to then access different information, you would use what's called a different endpoint, and then you could send GET, POST, PUT, or DELETE requests to that endpoint and do the same thing. Request some data, update some data, and it would all be through this endpoint. And it would have a different function on the server and store different data on the database. So the important concepts that I want to talk about that hopefully these analogies are helpful with is the URL is gonna be the address of your website. So that might be like arianstutorials.com if I wanted to have a website with a bunch of tutorials on it. So now the endpoint would the part of a website that you're trying to access at that time. So my tutorial met website might have different users 'cause different users can access different tutorials. Or it might be, there could be tutorials as well as an about page or the landing page, my homepage. So those would all be accessed from different endpoints. And then the client is gonna be the visual thing that the user is going to see. It's the public facing part of the website, the part that you'll look at in your browser. And then the server is gonna be like a non-graphical backend part of a website that handles the logic and says if the client is asking for a request, here is how I fulfill that request. And the database is where your data is stored. And so what we'll be doing today is creating a URL. We're gonna be using localhost, so it's only gonna be accessible on your computer. But at the very end of the lesson, I'll talk about different options that you can have for putting your website onto the internet so it can be accessed by anyone. And then also we're gonna be creating different endpoints, so different pages that can be accessed from different endpoints. And we're gonna look at a little bit of HTML, and CSS, and JavaScript. We're gonna be writing our server in Python using the Flask framework, and then the databases are a little bit more work than I want to show you today. You can read up on tutorials about how to do this and I will give suggestions for that as well at the end of the lesson. But yeah, we won't touch that today. So there's also this concept of different environments. So the development environment is the one that's on your computer where you write and debug code. And there is usually one development environment per team member. So each team member who's working on this website would have a different development environment on their own computer. So there's also an optional test environment. So when you have finished writing some code, you can push that code onto a test environment, run some tests to make sure you didn't break anything. So if there is one, it would just be one or more per team. And then a production environment is going to be the actual code that the public can access. So this is your live web app. It's accessible by anybody on the internet, and ideally it wouldn't break. And you've only got one per team that everyone accesses.