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
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:
.gif)
0 Comments