What is Web Application Architecture?
The web application architecture describes the interactions between applications, databases, and middleware systems on the web. It ensures that multiple applications work simultaneously. Let us understand it with a simple example of opening a webpage.
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?
With any typical web application, there are two different codes (sub-programs) running side-by-side. These are:
- 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
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.
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
A web application architecture is a pattern of interaction between various web application components. The type of web application architecture depends on how the application logic is distributed among the client and server sides.
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.
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
It is a software design pattern for developing web-applications. A MVC pattern is made up of following 3 parts:
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.
controller receives all requests for the application and then works with the
model to prepare any data needed by 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
“B2B” stands for “business to business” . B2B businesses sell products and services directly to other businesses. Or, more specifically, they sell to the decision makers in any particular business only via internet or directly.
“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!
Any web application in a working state can’t be labeled ‘the best.’ There is more than a working ability that makes a web application worthy to be called great.
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 web application architecture, like the Internet, is continuously evolving. The very basic model of the web application architecture appeared during the reign of Web 1.0. However, it was during the advent of Web 2.0 and Web 3.0 that it gained its present form.
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
WebSockets are primarily designed for server to browser communications, and while they can be used regardless in any client-server communication, they do not behave well in a server-to-server setup. The server hosts a web-socket server, and clients can open a connection to that server. This is popular now mostly because it is faster and less resource-hogging than older ways of solving the problem, like long-polling/COMET.
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.
Even though one of these is (exclusively) server-server and one is (mostly) browser-server, these technologies are often discussed in the same places, almost like they are solving the same problems. If you look up the chain high enough, you see that they both solve the problem of “real time” communication, but they solve different aspects of this problem in very different ways.
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 are sent over HTTP unlike WebSockets.
- 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
Pub/Sub is a publish/subscribe (Pub/Sub) service: a messaging service where the senders of messages are decoupled from the receivers of messages. … Publisher (also called a producer): creates messages and sends (publishes) them to the messaging service on a specified topic.
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.
Contrary to its name, Serverless DOES not mean the absence of servers (you still need servers in order for your app to be available online). It rather means that you don’t have to worry about server management, maintenance, monitoring, capacity planning, and scaling. You hand over these processes to a “serverless provider” and they take care of that for you.
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’
The term “Serverless” is confusing since with such applications there are both server hardware and server processes running somewhere, but the difference compared to normal approaches is that the organization building and supporting a ‘Serverless’ application is not looking after that hardware or those processes. They are outsourcing this responsibility to someone else.
What is Serverless?
Like many trends in software, there’s no one clear view of what Serverless is. For starters, it encompasses two different but overlapping areas:
- 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.
- 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
Let’s think about a traditional three-tier client-oriented system with server-side logic. A good example is a typical ecommerce app — dare I say an online pet store?
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:
- We’ve deleted the authentication logic in the original application and have replaced it with a third-party BaaS service (e.g., Auth0.)
- 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.
- 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.
- 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.
- 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