What is Web Application Architecture?

As soon as the user hits the go button after typing a URL in the address bar of a web browser, it requests for that particular web address. The server sends files to the browser as a response to the request made. The browser then executes those files to show the requested page.

Finally, the user is able to interact with the website. The most important thing to note here is the code parsed by the web browser. A web app works in a similar way.

This code might or might not have specific instructions that tell the browser how to respond with respect to the different types of user inputs.

Hence, a web application architecture has to include all the sub-components as well as the external applications interchanges for the entire software application, in the aforementioned case, which is a website.

The web application architecture is indispensable in the modern world because a major portion of the global network traffic, as well as most of the apps and devices, make use of web-based communication.

A web application architecture has to not only deal with efficiency, but also with reliability, scalability, security, and robustness.

How Does It Work?

  • Client-side Code — The code that is in the browser and responds to some user input
  • Server-side Code — The code that is on the server and responds to the HTTP requests

A web developer (team) developing the web application decides as to what the code on the server will do with respect to the code in the browser. For writing server-side code, C#, Java, JavaScript, Python, PHP, Ruby, etc. are used.

Any code that is able to respond to HTTP requests has the ability to run on a server. The server-side code is responsible for creating the page that the user requested as well as storing different types of data, including user profiles and user input. It is never seen by the end-user.

A combination of CSS, HTML, and JavaScript is used for writing the client-side code. This code is parsed by the web browser. Unlike the server-side code, client-side code can be seen as well as modified by the user. It reacts to user input.

The client-side code communicates only via HTTP requests and is not able to read files off a server directly.

Types of Web Application Architecture

There are 3 primary types of web application architecture. Each one of them is explained as follows:

  • Single-Page Applications (SPAs) — Instead of loading completely new pages from the server each time for a user action, single page web applications allows for a dynamic interaction by means of providing updated content to the current page.

AJAX, a concise form of Asynchronous JavaScript and XML, is the foundation for enabling page communications and hence, making SPAs a reality. Because single-page applications prevent interruptions in user experience, they, in a way, resemble traditional desktop applications.

SPAs are designed in a way so that they request for most necessary content and information elements. This leads to the procurement of an intuitive as well as interactive user experience.

  • Microservices — These are small and lightweight services that execute a single functionality. The Microservices Architecture framework has a number of advantages that allows developers to not only enhance productivity but also speed up the entire deployment process.
    The components making up an application build using the Microservices Architecture aren’t directly dependent on each other. As such, they don’t necessitate to be built using the same programming language.
    Hence, developers working with the Microservices Architecture are free to pick up a technology stack of choice. It makes developing the application simpler and quicker.
  • Serverless Architectures — In this type of web application architecture, an application developer consults a third-party cloud infrastructure services provider for outsourcing server as well as infrastructure management.
    The benefit of this approach is that it allows applications to execute the code logic without bothering with the infrastructure-related tasks.
    The Serverless Architecture is best when the development company doesn’t want to manage or support the servers as well as the hardware they have developed the web application for.

MVC or Model View Architecture

Model: It is the lowest level of the pattern responsible for Maintaining data.

View : It is responsible for displaying all or portion of the data to the user.

Controller: It is a software code (.js) that controls the interactions between the Model & View.

MVC is popular because it isolates the application logic from the User interface layer and supports separation of concerns.

The controller receives all requests for the application and then works with the model to prepare any data needed by the view. The view then uses the data prepared by the controller to generate a final presentable response.

It is an architectural style that structures an application as a collection of services that are loosely coupled and independently deployable.

Business marketing models

B2C” means “business to consumer.” B2C businesses sell products and services to customers for personal use.

For example flipkart, snapdeal are doing mostly B2C transactions while BHEL, NTPC are doing mostly B2B transactions. some companies like maruti , hero motors eyc are doing both B2B and B2C transactions, b2b with their vendors / suppliers and b2c with there customers .

Some Web App Development Tips!

In order to ensure a web application is able to give out maximum performance, a galore of points should be kept in mind during its development. The web app must:

  • Avoid frequent crashes
  • Be able to scale up or down easily
  • Be simple to use
  • Have a faster response time
  • Have automated deployments
  • Log errors
  • Not have a single point of failure
  • Solve the query in a consistent and uniform manner
  • Support the latest standards and technologies
  • Utilize strengthened security measures to lessen the chance of malicious intrusions


The robustness, responsiveness, security, etc. of a web application is greatly determined by the model and type of web application architecture one chooses. Hence, before getting started with the development, take time to explore all requirements, goals, and possibilities.

Do you have any web application development experiences that you would like to share with the community? Or something to say about the article? The dedicated comment window is always open.

I wish you luck with your next web app development project!

Web-sockets vs Web-Hooks vs Server Sent Events

It is possible to connect 2 servers using websockets, but that is not usually what they are used for.

WebHooks, on the other hand, work very well in server-to-server systems due to how they operate. They work by one server telling another server that it wants data sent to a certain url when something happens.

The confusion

One situation where there may be a direct comparison is if you are building an API that will be consumed by a third party server. In that situation, you could provide a webhook API or a websocket API. Both allow the third party to get updates quickly:

  • If you choose webhooks, that third party will still have to figure out a way to push the changes you are telling them about to their client’s browsers.
  • If you provide a websocket API, the third party can just set up their site so each of their users connects directly to your websocket API, and their servers have to do less work.

Web-sockets keep a socket open on both the client and the server for the duration of the conversation (this also makes servers stateful, which makes scaling more tricky). Webhooks require a socket to stay open on the server. On the client, the socket is only opened up for the request (just like any other HTTP request). Webhooks could be expensive both on the client (if you need to notify a lot of servers when something happens) or on the server (if you need to listen to updates from a lot of clients), but both just use HTTP, and the are a lot of solutions available for scaling HTTP services.

Comparisons between WebSockets and server-sent events

  • SSEs offer only one-way communication of events from the server to the client and DO NOT support a full-duplex communication as WebSockets do.
  • SSEs have the ability to automatically retry a connection; they also have event IDs that can be associated with messages to provide Quality of Service (QoS) features. The WebSockets specification does not support these features.

On the other hand,

  • WebSockets support full-duplex communication, and reduce the latency and help improve throughput, as there is an initial handshake over HTTP, but then, the messages are transferred between endpoints over TCP.

Publish/subscribe messaging, or pub/sub messaging

Publish/subscribe messaging, or pub/sub messaging, is a form of Asynchronous service-to-service communication used in serverless and microservices architectures. In a pub/sub model, any message published to a topic is immediately received by all of the subscribers to the topic.

Google and Confluent are in a partnership to deliver the best event streaming service, based on Apache Kafka, to build event driven applications and big data pipelines on Google Cloud Platform.

Serverless Architecture

In other words, serverless computing lets you build applications without thinking of servers.

Serverless computing, or more simply Serverless, is a hot topic in the software architecture world. The “Big Three” cloud vendors — Amazon, Google, and Microsoft — are heavily invested in Serverless. The most popular infrastructures are Amazon’s AWS Lambda Function, Google’s Cloud Functions, Microsoft’s Azure Functions. AWS currently dominates the market.

Serverless computing is a cloud computing execution model in which the cloud provider runs the server, and dynamically manages the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity.

Serverless architectures are application designs that incorporate third-party “Backend as a Service” (BaaS) services, and/or that include custom code run in managed, ephemeral containers on a “Functions as a Service” (FaaS) platform. By using these ideas, and related ones like single-page applications, such architectures remove much of the need for a traditional always-on server component. Serverless architectures may benefit from significantly reduced operational cost, complexity, and engineering lead time, at a cost of increased reliance on vendor dependencies and comparatively immature supporting services.

Origin of ‘Serverless’

What is Serverless?

  1. Serverless was first used to describe applications that significantly or fully incorporate third-party, cloud-hosted applications and services, to manage server-side logic and state. These are typically “rich client” applications — think single-page web apps, or mobile apps — that use the vast ecosystem of cloud-accessible databases (e.g., Parse, Firebase), authentication services (e.g., Auth0, AWS Cognito), and so on. These types of services have been previously described as “(Mobile) Backend as a Service”, and I use “BaaS” as shorthand in the rest of this article.
  2. Serverless can also mean applications where server-side logic is still written by the application developer, but, unlike traditional architectures, it’s run in stateless compute containers that are event-triggered, ephemeral (may only last for one invocation), and fully managed by a third party. One way to think of this is “Functions as a Service” or “FaaS”. (Note: The original source for this name — a tweet by @marak — is no longer publicly available.) AWS Lambda is one of the most popular implementations of a Functions-as-a-Service platform at present, but there are many others, too.

In this article, we’ll primarily focus on FaaS. Not only is it the area of Serverless that’s newer and driving a lot of the hype, but it has significant differences to how we typically think about technical architecture.

BaaS and FaaS are related in their operational attributes (e.g., no resource management) and are frequently used together. The large cloud vendors all have “Serverless portfolios” that include both BaaS and FaaS products — for example, here’s Amazon’s Serverless product page. Google’s Firebase BaaS database has explicit FaaS support through Google Cloud Functions for Firebase.

There is similar linking of the two areas from smaller companies too. Auth0 started with a BaaS product that implemented many facets of user management, and subsequently created the companion FaaS service Webtask. The company have taken this idea even further with Extend, which enables other SaaS and BaaS companies to easily add a FaaS capability to existing products so they can create a unified Serverless product.

A couple of examples

UI-driven applications

Traditionally, the architecture will look something like the diagram below. Let’s say it’s implemented in Java or Javascript on the server side, with an HTML + Javascript component as the client:

With this architecture the client can be relatively unintelligent, with much of the logic in the system — authentication, page navigation, searching, transactions — implemented by the server application.

With a Serverless architecture this may end up looking more like this:

This is a massively simplified view, but even here we see a number of significant changes:

  1. We’ve deleted the authentication logic in the original application and have replaced it with a third-party BaaS service (e.g., Auth0.)
  2. Using another example of BaaS, we’ve allowed the client direct access to a subset of our database (for product listings), which itself is fully hosted by a third party (e.g., Google Firebase.) We likely have a different security profile for the client accessing the database in this way than for server resources that access the database.
  3. These previous two points imply a very important third: some logic that was in the Pet Store server is now within the client — e.g., keeping track of a user session, understanding the UX structure of the application, reading from a database and translating that into a usable view, etc. The client is well on its way to becoming a Single Page Application.
  4. We may want to keep some UX-related functionality in the server, if, for example, it’s compute intensive or requires access to significant amounts of data. In our pet store, an example is “search.” Instead of having an always-running server, as existed in the original architecture, we can instead implement a FaaS function that responds to HTTP requests via an API gateway (described later). Both the client and the server “search” function read from the same database for product data.
  5. Finally, we may replace our “purchase” functionality with another separate FaaS function, choosing to keep it on the server side for security reasons, rather than reimplement it in the client. It too is fronted by an API gateway. Breaking up different logical requirements into separately deployed components is a very common approach when using FaaS.

Stepping back a little, this example demonstrates another very important point about Serverless architectures. In the original version, all flow, control, and security was managed by the central server application. In the Serverless version there is no central arbiter of these concerns. Instead we see a preference for choreography over orchestration, with each component playing a more architecturally aware role — an idea also common in a microservices approach.

For more read @ https://martinfowler.com/articles/serverless.html

Experience with Front-end Technologies and MERN / MEAN Stack. Working on all Major UI Frameworks like React, Angular.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store