Hi there! If you’re wondering who I am, I go by @iamaangx028 on the internet — you can call me Aang :)

I am a student interested in pursuing a career in cybersecurity. As part of that journey, I would like to share my progress with all of you through weekly blog posts.

Just a small note for continuity…

So far, we’ve explored several important topics that lay the foundation for understanding web security. If you’re new here, check out the earlier blogs for better continuity. This week, we’ll dive into the fundamentals of Modern Web Application Architecture — a key piece in the puzzle of building and breaking secure systems.

If you have a basic understanding of Web System design concepts, then it would be easy to understand the Web Applications architecture.

Web Application architecture is responsible for the foundation of a web Application. It defines the essential components of a web application and how they interact with each other. It also helps in covering how a web application should behave in different situations. How should it handle millions of users? How should it handle an unknown error? So, it's pretty much like an architect planning for a building, but in the digital world. Let us now try to understand the Web Architectures that are commonly used!

Modern Web Application Architecture

Scalability, Security, Reliability, and Maintainability are crucial for a Modern Web Application. Let us now look at different types of Web Application Architectures.

Client-Sever Architecture

This is the most used Web application architecture. And most of us are familiar with this type of architecture. The client-side consists of the UI (user interface). The Server-side consists of the Backend Servers (Web application server) and the Database. The client-side is responsible for taking the Inputs from the user and sending those inputs to the Backend servers over the internet. The Backend is responsible for processing the request according to the business logic. This is the most used web architecture.

Monolithic Architecture

In this type of architecture, all of the components are in a single entity. All of the UI (user interface) and backend server code, and the database are encapsulated into a single entity. It is easy to port and deploy, but very difficult to scale, update the code. So, this architecture is good for small to lower-medium-sized applications. But ideally, one should not be using this architecture if you are serious about building something impactful.

Microservices Architecture

In this type of architecture, all of the server-side code is divided into smaller, independent services. So, each function of the server-side can be done by any one microservice. These microservices communicate with each other using APIs/Message Queues. Each microservice is independent of the others. So, each microservice has its logic and even a database, for that matter.

Serverless Architecture

In this type of architecture, all of the backend is provided by the cloud service provider. The developers need not worry about setting up the servers and protecting them. Every backend component can now be provided by the cloud service providers. These cloud service providers follow the pay-as-you-go price model. So, you only pay for what you use. And the developers can use these services to deploy their web application. Here, both application developers and Cloud service providers are responsible for the security of the web application. They follow the Shared Responsibility model.

MVC Architecture

The MVC stands for the Model-View-Controller architecture. The Controller acts as the Postman. The model contains the logic and is responsible for talking to the Databases and retrieving information. The View is responsible for the Presentation of the data to the User, typically is responsible for the HTML that is forwarded to the User. But the Model and View never talk to each other directly. But the Controller acts in the middle and is responsible for making a request & receiving a response from the Model and View. The same happens with the View. So, the controller is responsible for managing the requests, responses, and errors.

Service-oriented Architecture

In this type of architecture, we utilize the services provided by other applications to run our web application. These services can be independent of each other. It is easy to scale the application in this type of architecture. But in this type of architecture, it is complex to manage and use them efficiently.

Single-Page Architecture (SPA)

In the SPA, all of the functionalities are placed in a single web page (HTML). The code is requested by the client, and the server sends most of the code to the client. And then the client does not need to make further requests to the server when accessing the other parts of the same web page. This is typically achieved using JavaScript Frameworks like React JS, Angular JS, Vue JS

Multi-Page Architecture (MPA)

In the MPA, for each new page requested, a request will be made to the server, and the server responds with the page content. This is a widely used architecture.

Progressive Web Applications (PWA)

These are web Applications that look like a Native App. But it is not. A PWA is OS independent. A PWA is like a web application with a manifest file, logos. A PWA can push notifications. PWAs are SEO friendly. PWA

Components of Web Architecture

Web Architecture has primarily Two Components called “Client-side/Front-end” and “Server-side/Back-end”.

Layers of Web Application Architecture

Then there are these layers called;

1. Presentation Layer
2. Application Layer/Business Logic Layer
3. Data Layer/Persistent storage Layer

Presentation Layer

The presentation layer is all about the User Interface (UI) and User Experience (UX). This layer is what the users interact with and give inputs into. This is the visible layer to the users. This is the client-side. This layer is so important that the user should be able to understand easily and interact with it. Otherwise, the business won’t be able to grow.

Application Layer/Business Logic Layer

This layer is like the Brain of the web application. This layer consists of web servers, application servers, and business logic. This layer is responsible for the data processing. It can talk to other components in the architecture. It is not seen by the end users. But it is still what decides what users should see. So, protecting the application layer is so important.

Data Layer/Persistent storage Layer

This layer is responsible for storing all of the data related to users and applications. It can store and retrieve the data whenever necessary. It can talk to other components when needed. It is also very important to secure this layer, as it contains the data related to all of the users and applications.

1-Tier, 2-Tier, 3-Tier and N-Tier

In these architectures,

1. If all three layers are on the same machine, then it is a 1-Tier
2. If any two layers, like Presentation & Application or Application or Persistent data layer, are on a machine. Then it is a 2-Tier
3. If all of these three layers are on three different machines, then it is a 3-Tier architecture application.
4. If more than three machines are used, it is called an N-Tier architecture.

Now, let us see the different technologies available and their purpose:

Languages used for Front-End and Frameworks

Modern web applications utilize various front-end technologies and frameworks. Each language has its significance, and each framework has its value. So, without diving deep into each language/framework, I have created tabular formats for front-end and back-end technologies and frameworks that give us the brief.

Languages used for Frontend

Languages used for Back-End and Frameworks

Backend Frameworks

Web Technologies used in Modern Web Apps

As we are more focused on the Security perspective of the web applications, for now, we just focus on knowing what it is and why it is. Let us list the modern web technologies that we should know at least a bit about..

I would like to wrap this week’s blog with this. This week, we mostly covered topics that most system Designers and Architects cover. The reason is that I don’t want to blindly go to a Web application and scratch my head. Of course, we did not go deep into every topic; we just touched the basics. Due to some personal commitments and travelling on weekends, I would like to conclude this blog here. Yes, I agree the fact that this week was lighter, but we touched on some heavy-hitting ideas. Next week, we’ll pick up the pace and dive deeper into security-specific concepts!

Got feedback, corrections, hit me up on X if you have something interesting to discuss!