As you read this, try and reflect back on how you got here. How is it that this text written somewhere on a word processor is visible on your display? What do you think happened between when you clicked a link (a URL) and this page appeared on your browser? In simplest terms, there were three components involved:
- Your browser
- The web server
- The database
The web server itself consists of many components, something we’ll discuss in a moment. So to answer our initial question- how did you get here?
- When you clicked a link, your browser located the corresponding webpage using DNS (Domain Name Server), often referred to as middleware.
- The web server responded to your browser’s request, fetched the requisite data from the database and sent it back.
- Your browser then formatted the data and is showing it to you. Any time you click somewhere on this page, the same process would repeat.
We have abstracted many of the complexities but that’s basically the gist of it. And this whole operation of how different components interact with each other is called web application architecture.
If we try and characterize these components, there are a few things you ought to know:
The web server essentially decides what you should see. It contains the business logic of the application and is arguably the most important part that determines the scale and performance of the application. The web server can be coded in virtually any language but the most popular ones include PHP, Java, Python, Ruby, among others.
A database is actually a part of the web server that stores the data that has to be shown to the user. It may also contain specific business logic depending on the architecture. SQL and NoSQL are the two main types of a database- each with many different variants.
Now that we have our basics clear, let’s take a step further into the types of web application architecture:
Single page applications
This architecture has gained much traction in recent years due to its improved user experience. What happens is that the web server maintains a dynamic connection with the browser so that each new information it sends is updated in the existing page rather than reloading this entire page. This kind of architecture makes extensive use of AJAX and XML.
Remember how we said that the web server responds to each request of a browser? Well, there are many different kinds of requests and this architecture creates a separate microservice (like a small server) for each functionality. All the microservices on a web server work independently and thus the response time is generally faster and also give developers the flexibility to deploy functionalities in a phased manner.
No, this doesn’t mean that application doesn’t have a web server. As you would expect, responding to browsers, processing business logic and storing data consumes a lot of computing resources like clock time, storage, and bandwidth. In serverless architecture, the web application development shifts the server to a third-party cloud that automatically manages all the requisite resources. The developers still have to build the web servers and database. They just don’t have to manage the infrastructure.
As we mentioned earlier, web servers itself has many different components and can have varying architecture. But that largely depends on the language you use for building your web server. The architecture of a web server built on Ruby would be different from Java servers or a Python server different from a PHP server. But that’s something you should ask from your offshore web developers for your particular application. There isn’t any architecture that is better than others and it all depends on the type of application and what expectations you prioritize.