For many decades we are browsing our favorite websites on the internet and getting a quick response whatever we want… but do you ever try to know how each part of the application works together and how is the request being processed behind the scene? If you’re a little bit familiar with tech then you may have a general and a common answer that your request goes to the web server, then the webserver processes the request and perform all the backend logic. After that, it sends the response back to the web browser and then you see the result in front of your screen.
Well, that’s exactly true but if you go on a deeper level, you’ll find that your web application has a complex architecture of different components and layers. Your request passes through these different layers and components and then you get the response back from the server’s end. It’s a quite long process but understanding the fundamental of web application architecture is really important if your goal is to become a good web application developer. Firstly let’s understand a few things about web applications.
When you’re building an application, you need to remember three principles in your mind…
- From the customer’s point of view, the application shouldn’t be complicated, it should be pleasing and it should address most of their problems.
- From a business aspect, your web application should stay aligned with its product/market fit.
- From an engineer’s perspective, the application should be scalable, functional, and it should be able to bear high traffic loads.
We will discuss the above points in web application architecture and we will understand the core concept, how the architecture works, its components, and types in detail.
What is Web Application Architecture?
Do you know that there is a difference between websites and web applications? ( you might have thought that both are the same). The web application is a program that runs on a browser and it has mainly three formal characteristics.
- Addresses a particular problem, even if it’s simply finding some information
- As interactive as a desktop application
- Works with Content Management System.
If we talk about the website then traditionally it’s just a combination of static pages. A website becomes a web application when it consists of both static and dynamic pages (yes!! it’s true that all modern websites are the example of web applications.)
Web application architecture is a mechanism that gives us a clarification that how the connection is established between the client and the server. It determines how the components in an application communicate with each other. It doesn’t matter what’s is the size and the complexity level of the application is, they all follow the same principle only the details may differ.
In technical terms, when a user makes a request on a website, various components of the applications, user interfaces, middleware systems, databases, servers, and the browser interact with each other. Web Application Architecture is a framework that ties up this relation together and maintains the interaction between these components.
When a user interacts with a website and gets the response back from the server’s end, the whole process executes within a few seconds. The most important thing we need to notice here is the code which has been passed to the browser. This code may or may not have particular instructions telling the browser how to respond with respect to the different types of user inputs. That’s why a web application architecture includes all the sub-components and external applications interchanges for an entire software application. A web application architecture has to deal with the reliability, scalability, security, and robustness due to a large amount of global network traffic.
How Does The Web Request Work?
Let’s take an example that you want to visit Flipkart.com.
- You enter flipkart.com in your browser: When you type the URL in your web browser and hit enter the web browser needs to know the address of the server where the page is located. So it sends the request to the DNS (Domain Name Server, which is a storehouse of domain names and their IP addresses ). After that browser sends the request to the found IP address using the HTTPS protocol. If you already have visited Flipkart.com earlier from the same browser, then it will pull the address from the cache.
- The web server processes the request: In the next step, the webserver sends the request to the storage area to locate the page and all data that follows with it. Here the Business logic (also called Domain Logic and Application Logic) comes in the picture. BL takes the responsibility of routing which means how each piece of data is accessed. It regulates this workflow specifically for each application. As BL processes the request, it sends it to storage to locate the looked-for data.
- You get the response back: When the response travels back, it displays in front of your screen. The web page (graphical interface) for any website which is displayed on your screen is called the front end of an application. Here you see all the UI and UX components to access the information.
How Does Web Application Architecture Work?
All the web applications run on the client-side and the server-side. When a user makes a request there are mainly two programs run on both sides.
- Code that runs in the browser and works as per the inputs of the user.
- Code in the server which responds to the HTTP requests
Web Application Architecture Components
Web application architecture works on various components. These components can be divided into two areas.
1. User Interface App Components: As the name suggests this category is much more related to the user interface/experience. In this category, the role of the web page is related to the display, dashboards, logs, notifications, statistics, configuration settings, etc and it has nothing to do with the functionality or working of the web application.
2. Structural Components: This category is mainly concerned with the functionality of the web application with which a user interacts, the control, and the database storage. As the name suggests it is much more about the structural part of the web application. This structural part comprises…
- The web browser or client
- The web application server
- The database server
Web Application Three Tier Architecture Layers
Web application architectural patterns are separated into many different layers or tiers which is called Multi- or Three-Tier Architecture. You can easily replace and upgrade each layer independently.
Business Layer: It is also referred to as a Business Logic or Domain Logic or Application Layer. It accepts the user’s request from the browser, processes it, and regulates the routes through which the data will be accessed. The whole workflow is encoded in this layer. You can take the example of booking a hotel on a website. A traveler will go through a sequence of events to book the hotel room and the whole workflow will be taken care of by the business logic.
Persistence Layer: It is also referred to as a storage or data access layer. This layer collects all the data calls and provides access to the persistent storage of an application. The business layer is closely attached to the persistence layer, so the logic knows which database to talk to and the process of retrieving data becomes more optimized. A server and a database management system software exist in data storage infrastructure which is used to communicate with the database itself, applications, and user interfaces to retrieve data and parse it. You can store the data in hardware servers or in the cloud.
Some other parts of the web application which is separated from the main layers that exist in the architecture are…
- Cross-cutting code: This part handles communications, operational management, and security. It affects all parts of the system but should never mix with them.
- Third-party integrations: Using third-party APIs we can integrate payment gateways, social logins, GDSs in travel websites, etc.
Types of Web Application Architecture
1. Single Page Applications: Today a lot of modern web applications are designed as single-page web applications that only include the most required elements and information to generate an intuitive and interactive user experience. In a single page application, the content or information is updated on the current page rather than loading a new page from the server for each action performed by the user.
- The application requests only necessary content details and it prevents interruptions in the user experience.
- Users can continue the interaction with the page while the contents are updated on the page (faster interaction).
2. Microservices: These are small and lightweight services that execute specific, single functionality. The components in the applications are not dependent on each other, so there is no need to develop each component using the same programming language. This gives the flexibility to the developers to choose the language or technology stack of their own choice. It enhances the productivity of the developers and speeds up the development process.
3. Serverless Architectures: In this approach, developers outsource the server and infrastructure management from a third-party cloud infrastructure services provider. The advantage of this approach is that it allows the application to execute the required or custom logic without worrying about the infrastructure-related tasks. This approach is mainly preferred by the companies who don’t want to manage or support the servers and the hardware they have developed the web application for.
Hope this was helpful in understanding the complete architecture of web applications. The web apps are continuously evolving and a lot of modern web development app has replaced the previous legacy structure and basic components. A lot of features of web applications such as robustness, security, scalability, reliability, responsiveness depends on the web application architecture one chooses to work with. The right web application architecture paves the way for future plans of expansion and scalability. So it’s always good to explore the requirements and goals before someone gets started with the development process of an application.