Architecture of Web Applications

A free video tutorial from in28Minutes Official
DevOps, Azure, GCP, Docker, Kubernetes, Java & Spring Boot
Rating: 4.5 out of 1Instructor rating
53 courses
1,054,186 students
Step 11: Architecture of Web Applications

Learn more from the full course

Learn Spring Boot 3 in 100 Steps - No 1 Java Framework

Learn Spring Boot 3 building a REST API and a Spring MVC Web application using Maven in 100 steps

28:52:00 of on-demand video • Updated July 2022

Learn Spring Boot 3 - LATEST version of Spring Boot Framework
Build Web Application and REST API with Spring Boot
Learn MAGIC of Spring Boot - Auto Configuration, Spring Initializr and Starter Projects
Connect to a Database using JPA/Hibernate and Spring Boot
You will learn to write great Unit and Integration tests using Spring Boot Starter Test
Spring Boot STARTER Projects - Spring Boot Web, Spring Boot Test, Spring Boot Data JPA, Spring Boot Data REST
You will understand how to make BEST USE of Spring Boot Actuator and Spring Boot Developer Tools
You will learn how to externalise application configuration using Spring Boot Profiles and Dynamic Configuration
You will understand and use the embedded servlet container options provided by Spring Boot - Tomcat, Jetty and Undertow
You will understand the basics of developing a Web Application - POST, GET, HTTP, MVC Pattern
You will understand the basics of styling your web page using Bootstrap framework
English [Auto]
Welcome back. We are in step 11 and in the step will take a small pause to take in the big picture of the architecture of Web applications. So we'll take a high level picture of how Web applications are typically developed. What are you seeing on the screens are the typical layers in a typical Java application. We have a web layer. You have a business layer, you have a data layer and you have an integration. Typically, applications either get the data from the database to talk to the database. We use a data layer. We talk to other applications. Let's say we are managing to lose, not in our own database, but we want to talk to a do management like wanderlust in that kind of a situation. I would need to talk to the services which are offered by that to do management application. Let's say I want to get the currency current values of currency stock values. I need to integrate with other systems so the integration layer helps me to integrate with other systems. The business layer in any typical application would be the one which has all the business logic for that specific application. So it would talk to the data layer, it would talk to the integration layer, get all the data it needs, calculator stuff around that and have all the business logic in here. So these are typically the important background ones. Once you have the business logic, you would want to actually expose either Web services on top of them or you would want to have applications using them. Either you are showing them in a Web application on a screen, or you are exposing rest services or social services to the outside world. All that kind of logic typically is in the web layer. So the web layer is the one which exposes all the business logic that you have to the outside world. In the NVC m stands for model, which is the business, so M is business and everything. And this is stand for M and V's view, which is the Giuseppe's as far as we are concerned right now, and C is the controller. The V and the C of the MVC are typically in the web layer. That kind of the typical architecture of any Java application. If you look at the typical framework choices in the Web applications, spillages is one of the basic ways of developing Web application. I doubt if anybody uses direct servlet today. Most of the applications use MVC framework of the kind of struct or spring MVC spring. This is quite the most popular MVC framework and that is what we are using in this specific application as well. As far as the View is concerned, you have multiple options. You have Giuseppe's LGT, so E-L and still make it easy to display data bindu binding and stuff in ADP. The other options are free marker and velocity templates and GSF. So these are kind of the options individually in view for them and for The View. And you are exposing restfully web services which are consumed from anthology's. So those are typically the things which typically are exposed from a web applique web layer of a typical Web application. Let's dig further into the model one and the model to architectures which are popular indefinably. The Model one architecture is basically from the browser. You send the request directly to ADP GSB. Right now what we are doing is from the browser. We are sending it to the controller and the controller sends it to the GSB model, one with one of the first architectures for web applications where from the browser the request directly was sent to the GSB. So it was not sent to the controller, but it was sent directly to the GSB. So the request went to the GSB. Jospeh handles that request and it would redirect to the next DSP. There were no concept of a servlet then, so all that we had was DSP pages. This was one of the first architectures which was used to developing Web applications. Obviously these have a lot of problems because the ISPs become huge. So JSP has all the control of logic, all of you logic and over a period of time also a lot of business logic. And these applications became unmaintainable and from there came in the model to architecture, the modern architecture from the browser. The request goes to the servlet. So from the browser, like when user submits a request on the browser, the request goes to this servlet. This tablet would talk to the business logic, would finalize the model and make it available to the viewer. And then the view would be rendered to the browser and the next request from the browser might go to a different servlet. With this kind of an architecture, we had a lot of popular frameworks in like Strat, for example, set one had this model architect model to architecture from the browser. You redirected the request directly to the servlet which are on the server model to friend controller. Architecture is an evolution on top of the model to architecture. So from the browser, we always send a request to a single controller. This controller is called a friend controller, for example, in Spring NVC. This is called despatcher servlet to dispatch. Usability is nothing but a friend controller. So what happens is all requests go to different controller. So whether you are sending a login request or a list to those request, it will always go first to the dispatcher servlet and from dispatcher. The dispatcher servlet says OK, slash login login controller slash To-Do list to lystra controller or to the controller based on the you are a different controller. Decide which controller to go to once controller returns the data back, it decide which view to render and it would send the response back to the browser from controller. So all data would be going through different controller in a model to architecture with different controller. Typically, this is the most famous architecture with MVC applications. The reason is the controller becomes the central point of the entire application so you can implement things like security and all that kind of stuff at singleplayer. So if I want to log every request, I can add it to a different controller. If I want to implement security around all the UI, I can do that in different controller. So all the centralized logic, I can start implementing it in different controller. The idea behind this step was to give you an overview of typical architecture of Java applications while we want to get our hands dirty. It's very important for you to get the big picture of how things are organized. So we looked at the different layers in a typical Web application where business data and integration, we looked at the different framework choices that are available in a web layer. We looked at the model one architecture where there were only Giuseppe's and Espy's became huge. And then we looked at Moraldo architecture, where the request directly went to different servlet at different points in time. And the last thing which we looked at was Morialta with different controller, where all the request from the first go to a controller and friend controller, then decide which controller to call. In the next step, we would start getting our hands dirty again until then.