How Do Web Applications Work?
Imagine your day-to-day routine where you open a browser and search for a website you frequently visit, let's say YouTube. When you type in YouTube, your browser might suggest youtube.com, and tapping it opens the YouTube page with videos recommended based on your preferences.
Let’s save the question: How are videos recommended? for future blogs.
Overall, it might seem a little simple for us to type in YouTube in the browser and get to see the videos that we want, but have you ever wondered what happens behind the scenes? How does our browser know what YouTube actually is? Not only YouTube, but also any other website that we visit online.
Also, if you have observed it, sometimes the YouTube page loads very quickly, while any other website you never visit that frequently, it takes much longer to load. The internet speed is not always the thing to take the blame here. Sometimes it’s because of a tech thing called caching, and we will cover this later in this same blog.
The tech behind the scenes amazes you. Let’s dive deep into this to know further.
A Brief Overview
It’s a bit of a lengthy story, so let’s break this into small sections for better understanding.
Browsers don’t know what the word YouTube means directly, but instead, browsers are good with IP addresses(a bunch of hard-to-remember numbers), and we humans are sick of remembering them.
Imagine a scenario where you go into the browser and type in youtube.com and get to see the desired page that you want.
Imagine another scenario, where you need to enter the IP address to get to see the YouTube page. It’s weird, right? We will be doomed if we were to remember IP addresses for every website that we visit.
For a normal human being, it is much easier to remember YouTube rather than a hard-to-remember sequence of numbers with dots in it (people call it an IP address).
To comfort the users, DNS comes to the rescue.
Think of it like a dictionary (key value hash) which maps the keyword (natural language domains) like youtube.com with the respective IP address (119.x.x.x). So it lets the browser figure out the IP address by letting the user just type in the domain name.
Once the Browser gets a hold of the IP, the browser will then request the machine running on the internet on that public IP (often called a Server) for the page the user requested.
The Server does its validations to identify malicious requests or unauthorized requests and accordingly responds. The browser then receives the response and renders it.
Let’s go deep into each topic.
I intend this blog to be both clear and insightful, so if you feel like you know a particular topic already, you can jump on to the next one without wasting time.
Quick Index
- What is a Client?
- What is DNS?
- What is a Server?
- What is CORS validation?
- What is Caching?
1. What is a Client?
Think of the Client like the web browser we use daily. The term Client is not limited only to the browser. Any kind of application that we use, like a mobile app, a desktop app, a web browser, etc., can be called a Client.
The technical definition of a Client should be “A Client is a machine or application that acts as a user interface and requests services from a Server and renders them accordingly for user visibility.”
The purpose of the Client is to make a request to the Server for the resources and render the resources with styling for the end-user visibility.
Client is the only application that the end-user interacts with directly, so several stylings will be applied to the pages using various Markup languages like HTML5 with CSS. (You might say React and Next frameworks, but internally, everything breaks down to raw HTML, CSS, and JS only).
Have you ever come across the word Abstraction? It is similar. Clients handle communication with servers and abstract (hide) the complexity from users, displaying only the pages that are intended for the user to see.
Let's stick to our example of a user entering youtube.com in the browser. Here, the browser is our Client requesting services for the page youtube.com.
Now, let's look into what happens next sequentially.
2. What is DNS?
The term DNS stands for Domain Name System.
Technically speaking, “DNS is a global hierarchical and distributed registry that maps human-readable domain names with IP addresses.”
What it actually does is that, when a client requests an IP address by providing the domain name, the DNS registry looks up that specific domain in its internal mappings, and if the domain is found, then the corresponding IP address is returned.
In our example, our Client is sending youtube.com to know its IP.
First, the browser checks in its Local DNS cache. What is this Local DNS Cache? We will cover this up later in the same blog ):
Let’s think that the domain is not found in the Local DNS Cache, then it goes and looks up in the global DNS registry (a distributed system of servers), which holds millions of domains and corresponding IP mappings. It performs a quick lookup for the domain we requested and returns the IP of youtube.com, let’s say 119.x.x.x is returned to our browser, aka Client.
IP is returned to the requested client, and the client will cache(save this) in Local DNS Cache for faster lookups next time, to reduce the network call to Global DNS.
Get Origin’s stories in your inbox
Join Medium for free to get updates from this writer.
Now the client has the IP of the server to request. Let's uncover the server now.
3. What is a Server?
You can think of a Server as a machine that is running continuously to serve the requests made by the Clients.
A technical definition of a Server will be something like “A Server is a computer or software program that processes requests from clients over a network and responds by sending the data back over the same network.”
To put it simply, a Server is a computer that operates independently and continuously over a network, while a client can request resources from this Server through a network call. There are many platforms available that offer cloud services, allowing users to run their Servers in the cloud, such as Amazon AWS, Microsoft Azure, and Google Cloud Platform (GCP).
Essentially, these platforms manage the machines and cover the associated infrastructure costs. For a machine to operate continuously, it requires electricity, and for global accessibility, it must remain connected to the internet nearly all the time. These service providers take care of the hardware and DevOps tasks on behalf of the users, charging them based on the resources they utilize and for the maintenance services provided.
In a typical architecture, web application Servers are responsible for serving user interfaces, while backend Servers manage data processing and storage. Between these two layers, middleware plays a crucial role. Middleware acts as a bridge, facilitating communication and data exchange between the web application Servers and backend Servers. It handles various tasks, including basic validations.
Past the validation layer, the actual machine will serve according to the user’s request and return the resources the Client has requested.
Web application Servers parse user requests to return the requested page.
In the case of backed Servers, they execute the business logic related to the user's request and return the appropriate response. These backend Servers also interact with the database(which is where the data is stored and is not accessible from the outside) to perform the necessary computations.
There will be cases where the same resource is being requested multiple times frequently, and in this scenario, caching comes to the rescue to reduce the computational cost and save time.
Ultimately, A Server is just a program running on a machine that listens for and responds to requests.
4. What is CORS validation?
CORS stands for Cross-Origin Resource Sharing. It is for blocking the resource requests from unauthorised clients.
To illustrate this concept more clearly, let’s consider a scenario involving three domains. Imagine that domains A and B are client applications, while Server C acts as the backend service that processes requests from these clients.
Let’s say we’ve configured Server C to accept requests only from domain A by specifying it in the allowed origins like this:
allowed_origins: ["domain A"]When a request is initiated from domain A to Server C, the server responds with the header Access-Control-Allow-Origin, and the browser enforces the origin validation. Since domain A is included, Server C processes the request and sends back a response. The browser then renders this response seamlessly within domain A.
However, if we were to make a similar request from domain B, which is not included in the allowed origins setup of Server C, the browser steps in to enforce validation. In this case, because domain B is absent from the allowed origins list, you would likely encounter an error indicating that the request has been blocked due to CORS (Cross-Origin Resource Sharing) restrictions. You might see an error like this, in this case.
Access to resource [request] from [domain B] has been blocked by CORS policy.
This approach ensures that the browser enforces domain validations. In the two scenarios described above, the server may process both requests, executing the logic and responding accordingly. However, the browser enforces CORS validation, and JavaScript running in the browser cannot access the server’s response, resulting in an error as illustrated earlier.
): Below is the complete flow discussed so far
One last thing to discuss is Caching.
5. What is Caching?
In the above scenario that we discussed, we discussed how the client requests the IP from the Domain, how to request the server, and how the server responds.
In any of the scenarios mentioned, the overall steps included are numerous, and repeating the same action every time will consume more time than anticipated. Therefore, the engineering principle called caching is introduced.
The term Caching refers to storing the frequently used data in our local machine temporarily to save network calls and reduce the overall latency.
DNS caching improves speed by avoiding repeated lookups.
In general, this caching can be of two types
- Client Side Caching
- Server Side Caching
Client Side Caching
In the scenario we discussed, the browser first checks its local DNS cache to find the IP address of the domain youtube.com. This step is taken to avoid making a network call to the global DNS, which helps save time and resources.
When a user frequently visits youtube.com, the first time their browser accesses YouTube and resolves its IP address through Global DNS, it creates an entry in its local cache. The next time the user tries to visit the same page, the browser retrieves the IP address from its local cache instead of making a network call. This process speeds up loading times, making it feel as though the page renders faster for the user.
Clients often cache static files, such as homepage themes and static images, which do not change frequently. This significantly reduces the time needed for data to be transferred during network calls.
However, caching can become problematic if we do not manage how long we store certain data. While cached data can be delivered quickly, it may not always be up-to-date. To ensure that cached data remains relevant, we assign a TTL (Time To Live) to each cached item. Once this TTL expires, the cached data is removed.
Server Side Caching
Caching can be implemented not only on the client side but also on the server side. For example, if multiple clients frequently request the home page, the server can store the most recent response in a caching service like Redis, along with a defined time-to-live (TTL). This approach allows the server to avoid executing the same logic for every request, making the response feel both fast and dynamic. When a new request comes in before the TTL expires, the server can return the cached data, thereby saving execution time and resources.
This is an example of caching, and most organizations implement it according to their specific business logic.
Since the memory allocated for caching is limited, caching relies on cache hits and cache misses to make efficient use of the available memory. It replaces less frequently used data with more frequently accessed data.
- A cache hit occurs when the requested data is found in the cache, resulting in a fast response.
- A cache miss happens when the requested data is not found, requiring a slower fetch from the server.
This pretty much covers it. So, the next time you open a website, I hope you’ll see it a little differently.
That was quite a journey, and we will end this here.
): Thank you for coming this far…
