Components of a Web Application Architecture

Introduction

Having a well made architecture means having components react to each other in an efficient, stable and most importantly, secure manner.

Web Architecture is no different. What we choose those components to be will reflect in the Application itself. When Web Applications comes to mind, there are usually two concepts that pop to mind, front end & back end.

Front End deals with what the user sees, how the website is formed and what is displayed on the browser while the Back End deals with information being interpreted from user queries in the background, on the server side.

As mentioned previously, in order to have a well working Web Application, the components or the model in which they reside should be chosen carefully.

Models & Components

The first model we will be looking into is Website with a singular Database.

This is the most commonly used system when it comes to web development and it is perfectly suited for testing or staging since there is little effort that goes in to deploying everything, but that does not mean that it is fit to be run in a commercial environment due to the lack of redundancy. If the only Server available goes down, the entire Website goes down.

The second model we will be discussing is when engineers use two web servers and only one database.
Having your web servers away from the database ensures greater security overall, since the database server can be locked tight even further. Two websites are plenty redundant and if one of them goes down, the other one keeps spinning. Of course here the problem is with the Database itself, if the DB goes down, the entire operation goes down as well.

The third model requires two databases and two web servers.

Since there are multiple points of failure, this is regarded a lot safer than previous options. The databases for example, can share information identically which means that one of them is usually passive and will overtake if the other one fails or the data can be shared evenly between them in which case they will both need to be working.

We talked about some models, now let’s talk about the web application architecture types themselves.

The Legacy HTML web app architecture is one of the most basic ways of communication. An entire HTML page is requested from the client and sent/received afterwards. This means that each time, the client needs to refresh the entire page in order to get information, not very sophisticated but it works.

Since there is no real background logic going on and there are no database queries or scripts running, this types of sites are considered highly secure, although not very effective for the end user since there is nothing to do but gather information

The following image displays the flow of such an engagement between the user and the Server.

Image Source

Coming to the rescue for diversity are Web Widgets.

Widgets are basically small chunks of code which temporarily fetch HTML Information when the users requests it and silently loads it in a block of code without the need to refresh the entire page. This makes the website experience seamless for the users.

And finally, we have the most currently used architecture, the Single Page.

This means that everything loads only once in a Single Page type of layout with full integration of JavaScript for example which handles all request logic from the clients and sends it back to the server to gather whatever is needed and constantly update the client without any obvious interference.

Conclusion

There are plenty of Models & Architecture Types to choose from and some of them could definitely prove beneficial for your situation.

Hopefully this article has shed some light on what that choice should be and has prepared you in your next Web Undertaking.