Architecture of Web Applications

in28Minutes Official
A free video tutorial from in28Minutes Official
DevOps, AWS, Docker, Kubernetes, Java & Spring Boot Experts
4.5 instructor rating • 43 courses • 619,809 students

Learn more from the full course

Learn Spring Boot in 100 Steps - Beginner to Expert

Become an expert on Spring Boot developing a REST API and a Spring MVC Web application using Maven in 100 steps

13:15:43 of on-demand video • Updated November 2020

  • You will learn the MAGIC of Spring Boot - Auto Configuration, Spring Initializr and Starter Projects
  • You will learn to develop RESTful web services with Spring Boot
  • You will learn to DEVELOP a Web Application connecting to JPA/Hibernate Step by Step with Spring MVC and Spring Boot
  • You will learn to use a wide variety of Spring Boot STARTER Projects - Spring Boot Web, Spring Boot Test, Spring Boot Data JPA, Spring Boot Data REST
  • You will understand Spring MVC IN DEPTH - DispatcherServlet , Model, Controllers and ViewResolver
  • 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 learn to write great Unit and Integration tests using Spring Boot Starter Test
  • 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 this step we'll take a small pause to take in the big picture of the architecture of job applications. So we take a high level picture of how web applications are typically developed what do we you're seeing on the screens. That typically in a typical job application you have a Webley you have a business really you have a date earlier and you have an integration. Typically applications that get the data from the database to talk to the database we use a data 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 two room management like Wunderlist in that kind of 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 current the current values of currency talk will use 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 where it has all the business logic for that specific application. So I did talk to the data earlier to talk to the integration layer get all the data I need to calculate stuff around that and have all the business logic in here. So these are typically the important background really. Once you have the business logic you want to actually expose either Web services on top of them or you'd want to have applications using them either you you're showing them in a web application on a screen or you are exposing risk services or soap services to the outside world. All that kind of logic typically is in the verb layer. So the Webley here is the one which exposes all the business logic that you have to the outside world. In the NBC EMS Tancer model which is the business is business and everything and this is stand for em and view which is the J.S piece as far as we are concerned right now. And C is the controller divi and the C of the MVC are typically in the valley. That kind of the typical architecture of any job application. If we look at the typical framework tristesse in the web applications symbologist is one of the basic ways of galloping web application. I doubt if anybody uses that Excel later today. Most of the applications use MVC framework of the kind of struts or spinning MVC spring. This is quite the most popular MVC framework and that is what we are using in this specific application aswell. As far as the view is concerned you have multiple options. You have just as easily just so easily and just will make it easy to display data bind to binding and stuff in edges. The other options are free marker and velocity templates and JSF So these are kind of the options in the view. I mean View for. Mean for the view and you you are exposing restfully Web services which are consumed from angry Agee's. So those are typically the things which typically are exposed from a verbally verbally or of a typical web application. Let's dig further into the model one and the Model 2 architectures which are popular in the family. The modern architecture is basically from the browser. You send data requests directly to a GSP. Right. What we are doing is from the browser we are sending it to the controller and the controller sent it to the Jews speak more with one of the first architectures for web applications where from the browser the request that it will send to the GSP. So it was not sent to the controller but it was sent directly to the DSP. So the request went to the JTP JCP handles that request and it would redirect to the next days. There was no concept of a server led then. So all that we had was DSP pages. This was one of the first architectures which was used to lipping web applications. Obviously these have a lot of problems because these pieces become huge. So JCP has all the control of logic or leave you logic and order period of time. Also a lot of business logic and this applications became unmaintainable. And from there came in the model to architecture the model to architecture from the browser. The request goes to the server. So from the browser like when you submit a request on the browser the request goes to the server let the server that would talk to the business logic would finalize the model and make it available to view. And then the view would be rendered to the browser and the next request from the browser might go to a different server with this kind of an architecture. We had a lot of popular frameworks come in like Strutt for example that one had this model architect model to architecture from the browser. You redirected the request directly to the sublet which are on the server model to friend control of 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 and we see this is called Dispatches solely to a dispatcher so it is nothing but a friend controller. So what happens is all the requests go to different controller. So whether you are sending a slash logon request or a slash list to requests it will always go first to the dispatcher servlet and from dispatcher so that the dispatcher said says OK Slashdot get log in controller flashily stewardess lista 2 controller or two controller based on the different controller decide which controller to go to. Once controllers don't get it back it didn't decide which view to render. And it would send the response back to the browser friend controller. So all data would be going through different controller in model to architecture with friend controller. Typically this is the most famous architecture with NBC applications. The reason is the controller becomes the central point of the application so you can implement things like security and all that kind of stuff at seeing people. So if I want to log every request I can add it to different control if I want to implement security around all the rails 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 job 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 will get different Crimble choices that are available in a player. We looked at the model one architecture where they were only just BS and just this became huge. And then look that model to architecture where the request directly went to different of late at different points in time. And the last thing which we looked at was more to do with front controller where all the requests from the browser first go to a friend controller and friend control and then decide which controller to call in the next step we would start getting our hands dirty again until then. All right.