How to architect your web application?

We don’t care much about application architecture initially in our career because as a fresher web developer, most of the projects we get are not that large and often hosted on shared servers. But it is always a dream to work on a fairly large project where these architectural things become more relevant. Generally in smaller companies you have to wear multiple hats from web development, server setup to deployment and even plan the architecture otherwise you might get in trouble in project projects.

This article will focus on those new web developers who either don’t have idea about architecting their application or are not much aware about the options they can choose. Let’s start now

A. Application code Level Architecture:

This classification is based upon the code level. We can divide application section based on server side and client side logics. We can call server side code as backend and client side code as front end. Based on this we can have following structure

1. Single Framework includes both front end and backend sections:

This is the simplest way where we manage front and backend as a single application. For example you use CakePHP which is a single application for both front end and backend. This structure is good for small and simple web application

2. One Framework for Backend and another framework for backend:

This is the structure where we use a framework application for back end and another framework application for front end code. For example you are using CakePHP as backend application and angular.js as front end application. Front end is communicating with backend through some webservices or APIs. This is suitable for larger web applications

B. Main Server level Architecture:

You have selected your approach from the above based on your application size and now we have to see how we will deploy this on the server. So here comes the server level architecture. You have following options:

1. Everything on one server:

You have a single server and you have to host you application on this single server whether you choose single code application or different front end and backend, everything including resources (Files and images) will be on same server. This configuration is suitable for small projects

2. Application and database on same server but resources on different:
You can keep application code and database on a server and resources like files and images on different server like AWS S3. This way your server can be configured for performance and not waste server energy for storage. This is also suitable for medium to bigger projects

3. Application, database and resources on different servers:

This is the complete segmentation of application for good performance. You keep application, database, and resources on different server so that it is easy to best optimise servers for their purpose. This setup is suitable for bigger projects

4. Application server, database server, resources server and caching server configuration:

This is advance version of above configuration with caching server included for performance. Some of the caching solutions are memcached and redis. Caching is used to reduce database requests and improve performance. This setup is also suitable for larger projects.

5. Application server, database server, resources server, caching server and searching server:

This is the extensive and more advance setup of the above configuration. It has searching solution like elastic search as a different server to solve and increase performance for searching data. It is suitable for larger projects where searching is main focus.

C. Load Balance for Bonus performance:

For better performance we use load balancer at server level. We can have separate load balancer for front end and backend application in which setup we have multiple instance of same application with different configuration like different RAM, CPU etc. and load balancer manages to route request to particular instance based on traffic load which ensure virtually 100% availability regardless of number of requests.

I hope this article helped you to think about architectural view for your application. Pretty soon you will have practical guide based article so keep tuned.