Either if you build a house or make a pizza, the base is significant. You need to make it strong enough to handle the entire construction; you need to estimate the load and choose materials with excellent characteristics if you don’t want your house to fall apart in a year (and all your investments to be wasted.) A home-made pizza should be easy to cut, soft but crispy no matter how much chorizo or cheddar you put on the top. So a proper amount of ingredients is essential, as well as your cooking and planning skills.
No matter what you invest your money, time, and efforts to – either a house, a pizza, or a web application – a strong base, ingredients, and construction impact its future.
Today, you are going to find out the essentials of web application architecture. Why is that so important? How to develop a robust but scalable web app architecture? And what tools and technologies may help with that? Keep reading to discover the answers.
How does a web application work?
Let’s start with the basics.
A web app consists of two separate parts running side by side. These are the front-end and the back-end of the application.
- Front-end or client-side is the part visually accessible to a user. The code runs in a browser. To create this part of an app, software engineers build markup in HTML/CSS and use JavaScript and its frameworks for user interface development.
- Back-end or server-side is a part that users can’t access. It runs on a server and responds to HTTP requests sent from the front-end part. The app server-side is responsible for storing and processing data. Some of the well-known server-side development languages are PHP, Ruby, Python, Java, and Node.js JavaScript framework.
App’s front-end and back-end complement one another. They use HTTP requests to share data; they are not interchangeable. While client-side code can’t read data from the server, server-side code can’t build the web page’s user interface. Running side-by-side, client-side and server-side code create web products we are now accustomed.
To illustrate the process, let’s open any web page:
1. Visiting clockwise.software
You enter the URL in the browser’s address bar. The browser recognizes your request and sends it to the server using the HTTPS protocol.
2. Processing the request
The web server catches the requests and replies with HTML code – standard code understandable by your browser.
3. Parsing
A browser analyzes received code.
4. Getting additional data
A browser downloads needed assets like images or fonts, while on a back-end, a web app connects to third-party services if required, for example, on payment gateways or maps.
5. Rendering
A browser brings all data together and builds a web page you requested.
An optimized web app responds to your request within a second. Dozens of requests fly one way and another while you’re reading this sentence.
It may seem like a browser does most of the job. But that’s not entirely true: you can see around 20% of developers’ efforts on a web page you open. About 80% remain in the shadow and make everything from buying a book on Amazon or sharing a tweet to communication with your partner on Zoom possible. There is a complex structure built of programming code users cannot see.
That’s a web application architecture that defines how your request is processed and what happens behind the curtain.
Web application architecture explained
Web application architecture is the entire system that describes components of a web app, connections, relations, and dependencies between them. It defines how back-end and front-end elements are organized, how they communicate with each other and external services, how they scale and build a unified software product.
In the Clean Code Blog, we can read about “the screaming architecture.” The author states that your web app’s architecture must “scream” the type of your app. The architecture defines what you build: either it’s a social network, an eCommerce app, or a delivery app similar to Uber Eats, it is critical to construct the architecture in accordance with the app’s requirements.
According to Ralph Johnson, the author of Design Patterns: Elements of Reusable Object-Oriented Software,
“(architecture) is a decision you wish you could get right early in a project”
So, probably in a project discovery phase, your engineering partner offers you a web app architecture as one of the expected deliverables. Although it may seem like only mature products require investments in architecture, even the smallest solution needs to be built on solid ground, with a clear vision of how to scale it.
Of course, if scaling and growth do belong to your goals.
- Web application architecture defines if your app meets technical and business requirements
- It allows scaling, re-building, and optimizing your product for better performance and security
- Architecture design requires a deep understanding of the product and strong cooperation between business and engineering departments.
Take a look at web app architecture, simplified:
In the center of a diagram, you can see the application core. It’s not only the core of a diagram but also the core of your app: here, the product’s essence, goal, and business purpose find the reflection in code. Other application layers don’t impact the core. Domain services implement interface entities. Outside the application core circle, there are two separate components: user interface and app infrastructure. The user interface includes various view models, and infrastructure is made with multiple elements like repositories. Both UI and infrastructure directly depends on the app’s core but don’t impact one another.
External dependencies, third-party services, databases, and servers are outside the circle of the clean architecture.
Based on the simple explanation, let’s have a glance at some key features of the clean architecture:
- Independency
A well-thought structure means that you can easily change your product’s UI – and nothing falls apart. You can migrate from MySQL to MongoDB and backward – and it won’t harm your system and its business purpose. Essentially, you can modify each component of your app, replace it or refactor, but it won’t have a direct negative impact on other app’s features.
- Testability
It is crucial to make your product easy to test as its quality influences its future success.
Clean architecture principles mean that to test one or another component of the system, a QA specialist doesn’t need access to any database, server, or external services.
- Scalability
Your business growth and application extension are connected. It’s essential to build a structure that is easy to scale. Clean architecture means scalable architecture as well.
- Maintainability
Web app-related business is a marathon, not a sprint.
So a high-quality software app should be a long-term tool for customer engagement and acquisition. A web application should be easy to support and maintain to provide a high level of experience and serve business needs.
5 software architecture patterns you may use for your product
Architecture is an art. Web application architecture may turn into a work of art, too.
There are multiple ways to get it done. Software architects suggest methods to create impeccable architecture, write books about the most commonly used architecture patterns and generate new solutions to reach the best results. It’s a challenge to find the truth and advice in gigabytes of digital data. Thus, in this article, we collected five architectures Mark Richards describes in his book Software Architecture Patterns. Dive deeper into architecture’s specifics, widen your awareness and build a better vision of constructing your web product.
1. Layered architecture
Layered, a.k.a. n-tier, architecture is one of the most common principles. Software engineers “wrap” an entire app around a database. The web looks like a digital onion: data, or user request, enters an app on the top layer and moves down to the core. On its way, it penetrates multiple layers that check, process, modify, re-build or translate data to a programming code understandable for the next layers.
Well-known MVC structure (which stands for Model-View-Controller) is a layered architecture. Software engineers use HTML/CSS and JavaScript to develop the View layer – a layer users interact with. The Model embodies the app’s core, and the Controller enables interaction between the inner and upper layers.
- Pros: each layer of the n-tier architecture is focused on its particular role. It enables the separation of concerns: changes in a specific layer don’t affect other layers. It meets the clean architecture requirement: layers are isolated, thus, easier to test and refactor.
- Cons: code may turn into a mess. Some modules may be separated between different layers; long-lasting inorganization may turn an app into a monolithic piece of code, extremely hard to maintain and scale.
When you should use a layered architecture
N-tier architecture may serve you well if you want to cut time to market. It’s the right choice for simple MVP and proof of concept. It’s common among inexperienced developers as it allows them to practice on MVC structure and build a clear understanding of a software product.
2. Space-based architecture
If the entire web solution is built around a single database, and the volume of requests or number of users snowballs, the moment may come when the database will no longer be able to handle the load. Then, the entire structure goes down.
Space-based architecture means that the load is distributed on several servers. This pattern is also called cloud-based architecture, or a distributed architecture.
Distribution may simplify and speed up multiple tasks. However, data analysis may become more complex, as there are numerous data storages.
- Pros: space-based architecture enables better performance and may save a web solution from failing.
- Cons: load testing may be difficult. An extremely high volume of data is needed to test the distributed system correctly with high capacity.
When you should use a space-based architecture
Space-based or cloud architecture is the right choice for high-load systems, online streams, and social networks: these sorts of applications collect, store, and process much data. By distributing data over multiple clouds, software engineers get higher performance and better maintainability.
3. Event-driven architecture
N-tier architecture means that data passes all layers even if it doesn’t have to do so. It may cause, among other examples, increased page load time, delayed response to users’ actions and requests, etc.
How to avoid that?
The event-driven pattern comes up with the answer.
Following this approach, a software engineer builds specific modules that “collect” all the input data and then redirect it to modules responsible for a particular type of action. Each module interacts with particular events only; it leads to better performance and better user experience.
- Pros: event-driven architecture is easy to extend. A new module accompanies a new feature or a new type of event without impacting other functionality. The structure remains stable and grows at the same time.
- Cons: proper testing may turn to a headache. It is impossible to test the specific feature before the entire system is ready. If several modules have a common event to react to, it is hard to identify the possible issue and, as a result, to fix it.
When you should use an event-driven architecture
The event-driven pattern serves best the asynchronous systems. Besides, if you can easily define how to cut your app into several modules, each handling a specific sort of tasks, you may find event-driven architecture quite handy.
4. Microkernel architecture
As Wikipedia says, “microkernel is the near-minimum amount of software that can provide the mechanisms needed to implement an operating system.”
According to Ralph Johnson, Eclipse IDE is an example of microkernel architecture. The tool handles multiple tasks. Some of them, like file opening and editing, is part of a microkernel.
The point is to put some basic tasks into a microkernel. For example, in your app, a microkernel may ask for a user name, process a simple request, check if the payment is completed, etc. On top of the microkernel architecture, you can add various plugins and extend your app’s functionality. This is why this pattern may also be called “the plugin architecture.”
- Pros: the architecture allows differentiating routine tasks from critical operations and handles the routine in the background. This may contribute to overall app performance.
- Cons: it’s a challenge to ascertain which tasks should be put in a kernel. The development of relations between plugins and kernels requires defined must-follow rules. Code refactoring and microkernel modification may be difficult: the more plugins depend on a specific kernel, the more challenging it is to change it.
When you should use a microkernel architecture
If you can see clearly what part of your app belongs to a kernel, this sort of architecture may serve your needs. Besides, if there’s a defined amount of routine tasks your app handles, along with a part that dynamically changes, it may be an excellent choice to turn routine into a microkernel.
5. Microservice architecture
Once you build a small, good-looking MVP, everything’s well.
Then, you add another tiny feature on top of the construction.
Then, you add more, according to your users’ needs and investors’ expectations.
Then, you build payment functionality and connect it to a third-party service.
Then, you add more and more, and ask for more feedback, and grow a user base, and put more cream and jam and onion on top of your initially small, good-looking pie.
Eventually, you find yourself unable to support and extend the enormously big, wildly miscellaneous structure.
And what if you put each feature into another plate and serve it separately on a festive table?
That’s how microservices work. You separate different features and build them as individual services. You connect each microservice gently to an app, refactor, modify or delete it if needed, without harming the structure.
- Pros: powerful digital companies like Netflix use microservices architecture pattern. It allows easily to scale the product, adjust it according to users’ demands, improve, fix and maintain each component separately.
- Cons: it is hard to cut an app to fully independent components.
When you should use a microservice architecture
Consider several use cases:
- You build a multi-component web app - an app that consists of several independent pieces of functionality;
- Your business develops rapidly, and it’s essential to develop and deploy multiple features simultaneously;
- You work with a distributed engineering team.
Tools for web application architecture
Searching for a perfect technology stack for web app architecture across the web, you may find numerous opinions and articles praising one or another technology.
The Web Application Architecture: Principles, Protocol, and Practices tells about several approaches to web application development. Depending on a chosen method, a software engineer may use Java Servlet API for dynamic web pages development, code in PHP, develop scripts, employ ASP.NET Core, etc.
However, there’s another point of view: the independence of frameworks. There’s the opinion that your product’s architecture should be resistant to technology changes. A tech agnostic approach gives you more flexibility and options to pick from; it allows your development team to employ the technologies they have substantial experience with. More options - more ways to build a better product.
The software engineering market offers dozens of tools and solutions for solving architectural tasks, but ultimately,
“Your architecture should tell readers about the system, not about the frameworks you used in your system.”
Final thoughts
With a clear vision of how web apps work and what’s happening on the back-end while a user clicks through the website, you can build better ideas and solutions for your next web product.
Each of the patterns we’ve considered has its own specifics, pros, and cons. Save the table so you can shortlist the best approaches:
Still, web application architecture design is a complex task that requires strong engineering skills and a solid background in server-side development. So before making a final decision, turn to your engineering partner for an expert opinion or a piece of advice.
