The internet is steadily moving towards active user engagement and extended functionality offered by web apps. As they are replacing websites, more and more developers are interested in how to develop web apps and attract more visitors to their web resources.
One of the challenges any aspiring developer can encounter before trying their hand in web application development is choosing the type and the component model of web application architecture. Our article will dot the ‘i’s on the matter and help you choose well.
Web application components
Web application architecture is a pattern of interaction between web application components. However, this definition is somewhat ambiguous, since when we talk about components of a web application, we can mean two things.
The first one features UI/UX web application components: dashboards, notifications, activity logs, statistics, settings, and many others. As you may have guessed, it has nothing to do with a web app architecture we want to discuss here, but rather with an interface layout plan.
To build a server side you need PHP, Python, Java, Ruby on Rails, .NET or Node.js development skills. This side usually consists of at least two more parts: app logic, or the main control center, and database, where all persistent data is stored. There can be also other components, which we’ll discuss in the next section.
Models of web app components
For a web app to be stable and fail-proof, it’s important to leverage components of a web application and choose a model that suits your specific business needs.
One web server (with database)
This is the simplest and the most risky model, where a single database is a part of the web app’s only server. If the server goes down, so does the web app. Such a raw model may suit some test projects or private practices. Still, if you want your web app to be reliable, we suggest looking at the other options.
Two+ web servers, one database
To scale web servers horizontally, you need to have your database run from a physically separate machine than a webserver. The idea is for a webserver not to store any data: even when it gets information from a client, the webserver processes it, writes the data to the database, and forgets about it. This is also known as ‘stateless architecture’.
With at least two web servers, you avoid a single point of failure. Even if one of the web servers will ever go down, another one will take over immediately. All requests will be automatically readdressed to the new server, and the web app will keep running. Also, a database run from a separate machine is better protected and vetted. Still, if your only database crashes, the entire system will crash as well.
Two+ web servers, two+ databases
With this model, you have two options: databases store identical data or have the data evenly distributed among them. In the first case, no more than 2 databases is usually needed; when one is down, the other can replace it, loss-free. Since data aren’t replicated in the second case, some data may become temporarily unavailable if one of the many databases crashes.
Still, this model is considered the most fails proof: neither web servers, nor databases have single points of failure. If the scale is large, with more than 5 web servers or databases, it’s also wise to have load balancers installed. They will analyze all incoming requests and shrewdly allocate them to keep the workload under control.
Types of web application architecture
Regardless of the model, all web application components always work simultaneously and create an integral web app. Depending on how the app logic is distributed among the client and server sides, there can be various types of web application architecture.
Legacy HTML web app
According to the very first and basic web app architecture, a server, consisting of web page construction logic and business logic interacts with a client by sending out a complete HTML page. To see an update, the user needs to fully reload the page or, in other words, to have the client send a request for an HTML page to the server and load its entire code once again. Look at this type’s web application architecture diagram below.
Since all the logics and data are stored on the server and the user doesn’t have any access to it, this architecture type is highly secure. Still, due to constant content reload and huge data exchange, it is more common for static websites than actual web apps.
Widget web app
In this type, the web page construction logic is replaced by web services, and each page on the client has separate entities called widgets. By sending AJAX queries to web services, widgets can receive chunks of data in HTML or JSON and display them without reloading the entire page.
With real-time widget updates, this type is more dynamic, mobile-friendly and almost as popular as the next type. Yet, this web application architecture requires longer development time and is less secure due to the app logic partially shifted to the exposed client side.
Single-page web app architecture
Chunks of data transferred from the server to the client here are minimal, especially compared to the first type. It’s very agile, responsive and lightweight web app that can be easily transformed into a mobile app with the help of hybrid wrappers such as Cordova/PhoneGap.
Web app architecture types and component models have been evolving together with the web itself. While the legacy structure and a basic component model appeared in the times of Web 1.0, modern web application architecture types and scalable component models are more common for Web 2.0 and 3.0 eras.
p style=”box-sizing:border-box;margin:0px0px12px;padding:0;”>The choice of a model and architecture can determine how responsive, robust, secure and fast your web app will be. So before launching the development project, take a closer look at your business needs and evaluate all possible options.