‫Up until this point,
‫we have just written our code without thinking much
‫about our application architecture.
‫It wasn't really important until now,
‫but now that our app is really starting to grow,
‫we need to start worrying
‫about the way that we design, or code architecture.
‫And this lecture will just be a brief introduction
‫to back-end architecture.
‫Starting with the MVC architecture.
‫So, in this project, we're going to use
‫a widely used and well known architecture
‫called the model, view, controller
‫or MVC for short.
‫And there are different ways
‫of implementing the MVC architecture,
‫some more complex than others,
‫but we're going to implement it
‫in a very straightforward way here.
‫I just wanted to let you know that
‫if you Google around for MVC,
‫you'll find it implemented in some different ways.
‫Okay, anyway, in this architecture,
‫the model layer is concerned
‫with everything about applications data,
‫and the business logic.
‫And we're going to learn what business logic means
‫in the next slide.
‫Next up, we have the controller layer
‫and the function of the controllers
‫is to handle the application's request,
‫interact with models,
‫and send back responses to the client.
‫And all that is called the application logic.
‫Finally, the view layer is necessary
‫if we have a graphical interface in our app.
‫Or in other words, if we're building
‫a server-side rendered website,
‫as we talked about before.
‫In this case, the view layer consists basically
‫of the templates used to generate the view,
‫so the website that we're going to send back to the client.
‫And that is the presentation logic.
‫For now, we're just building an API though,
‫so we're not really concerned about views just yet.
‫That's for a bit later in the course.
‫So using a pattern, or an architecture like this
‫allows us to write a more modular application,
‫which is going to be way easier to maintain in scale,
‫as necessary.
‫And we could take it even further,
‫and add more layers of abstraction here.
‫But in this kind of smaller application,
‫the MVC architecture is more than enough for our needs.
‫Now, all this may sound a bit abstract,
‫so let's take a look at MVC in the context of our app,
‫and the request-response cycle.
‫So as always, it all starts with a request.
‫That request will hit one of our routers,
‫because remember, we have multiple routers.
‫Basically, one for each resource,
‫like tours, users, et cetera.
‫Now the goal of the router is to delegate the request
‫to the correct handler function,
‫which will be in one of the controllers.
‫And again, there will be one controller
‫for each of our resources,
‫to keep these different parts of the app nicely separated.
‫Then, depending on the incoming request,
‫the controller might need to interact
‫with one of the models,
‫for example to retrieve
‫a certain document from the database,
‫or to create a new one.
‫Once more, there is one model file for each resource.
‫After getting the data from the model,
‫the controller might then be ready to send back a response
‫to the client, for example, containing that data.
‫Now, in case we want to actually render a website,
‫there is one more step involved.
‫In this case, after getting the data from the model,
‫the controller will then select
‫one of the view templates and inject the data into it.
‫That rendered website will then be sent back
‫as the response.
‫In the view layer in an Express app
‫there is usually one view template for each page.
‫Like a tour overview page,
‫a tour detail page, or a login page.
‫In the example of our latest app of course.
‫So, that is a broad overview of the architecture
‫that we're going to implement in this project.
‫Now to finish, let me just go into
‫a bit more detail on model and controller.
‫So, one of the big goals of MVC
‫is to separate business logic
‫from application logic.
‫You'll hear about these types of logic all the time
‫when you browse Stack Overflow,
‫or some site like that.
‫But what are these types of logic actually?
‫Well, the difference is a bit opinionated,
‫but this is my take on it:
‫So, application logic is all the code
‫that is only concerned about
‫the application's implementation
‫and not the underlying business problem
‫that we're actually trying to solve with the application.
‫Like showing and selling tours,
‫managing stock in a supermarket,
‫or organizing a library, for example.
‫So again, application logic
‫is the logic that makes the app actually work.
‫For example, a big part of application logic in Express,
‫is all about managing requests and responses.
‫So, in a sense, we can also say
‫that application logic is more about technical stuff.
‫Also, if we have views in our app,
‫the application logic serves
‫as a bridge between model and view layers
‫So that we never mix business logic
‫with presentation logic.
‫All right?
‫Now, about business logic,
‫it's all the code that actually solves the business problem
‫that we set out to solve.
‫Let's say again, that our goal is to show tours to customers
‫and then sell them.
‫And the code that is directly related to the business rules,
‫to how the business works,
‫and the business needs, is business logic.
‫Now if that still sounds a bit too philosophical,
‫some examples in the context of our latest app
‫are creating new tours in the app's database,
‫checking if a user's password is correct when he logs in,
‫validating user input data,
‫or ensuring that only users who bought a certain tour
‫can review it.
‫So all this stuff is concerned with the business itself,
‫and so it's part of the business logic.
‫Now, we need to keep in mind that
‫application logic and business logic
‫are almost impossible to completely separate,
‫and so sometimes they will overlap.
‫But we should do our best efforts
‫to keep the application logic in our controllers
‫and business logic in our models.
‫And there is even this philosophy of
‫fat models, thin controllers,
‫which says we should offload
‫as much logic as possible into the models,
‫to keep the controllers as simple and lean as possible.
‫So a fat model will have as much business logic
‫as we can offload to it,
‫and a thin controller will have as little logic as possible,
‫so that the controller is
‫really mostly for managing the application's requests
‫and responses.
‫Okay?
‫So, now keep all this in mind as we move on
‫and progress into building our applications.