We all know and love multiple different web applications and even use them in our day to day life.
Web applications are applications that use your internet connection to run on a web server instead of being locally stored on your computer. Users access web applications through a web browser. A common example would be – Gmail.
Have you ever wondered what goes on behind every click of the websites you visit? You click on “inbox” and Gmail shows you the mails stored in your mailbox but have you ever wondered what goes on behind the scenes to make that happen?
What’s under the curtain of every link you click on? How does the world wide web work? Which technologies are involved in these acts?
If these are the questions that you keep you up at night, then this might be the perfect article for you.
Today we’ll try to demystify a little part of that magic together. Let’s dive in, shall we?
The internet is formed by computers talking to each other.
There are certain rules and regulations that are followed for the exchange of information between computers.
But how do they know each other?
Imagine you are sending a letter to your friend, you would clearly define yours and your friend’s address on the cover of the letter so that it is shipped to the right address.
Similarly each of the computers in a network is given an address that uniquely identifies it in a network. It more or less looks like this:
And the world wide web, as we know it, comprises the computers and thrives by the connection among them.
How Web Applications Work
“Okay, so, we can uniquely identify the computers that talk to each other, but what actually goes on behind the scene?”
You may ask.
So, let’s say you entered www.google.com on the browser search bar, you press enter and boom! You are in the Google homepage, ready to browse anything you want.
We can categorize this whole journey in 3 parts:
- URL process and sending of requests
- Reception of request and proper response by the server
- Displaying the web page
Still with me? Good. Now, let me break down those three steps for you.
1. URL process and sending of requests:
This step has two parts. URL processing and request sending.
Any website you want to visit is formed up of different codes of different programming languages.
Now , you certainly did not write those, so they are not on your computer.
The codes are on other computers , which maybe in another part of the world, called a server.
Why is it called a server?
Because it is practically serving you with something, in this case, the web page you want to visit.
So you need to make a request to the computer holding the code. The link that you typed is called an URL(Uniform Resource Locator). This is used to locate resources on the web, in this case, the website you want to visit. In technical terms, the browser in this case is called a client. So a client is requesting a server to serve some web pages or information.
I know this is a lot of technical jargon to absorb, but stay with me.
Remember the string of numbers we talked about? The 126.96.36.199 IP address? Well, it turns out, the IP address is used to connect to the server so that you can get the page you requested.
But wait, you typed the link www.google.com right? You didn’t type in some weird numbers to get to google!
It turns out that the URL you typed is mapped to the IP address of the browser. This is done by another server (computer) called DNS Server. DNS stands for Domain Name System. You can think of this as a server that has a system of mapping the URL you typed with the ip addresses that you want to visit. So it simply works as a translator. If you want to know how this works, check out this link.
You might wonder how the browser knows the address of the DNS servers. Technically every browser knows the address of these DNS servers by default, they are programmed that way.
Told you, Magic!
Okay, so, the URL is processed to the IP of the server that we want to collect information from. Then comes the part of a request.
A request is more than a fancy name or a technical term, because a lot goes on behind each of the requests.
A typical browser request for play.google.com homepage looks looks like this:
As you can see there is lots of information sent by the browser when a certain request is made.
Things like the actual URL, the type of request, status code of the request and various metadata(data about data) are sent to the server to get the response as needed.
You should know that there are varieties of requests sent by a browser.
The request that the browser sends when you are logging in to a website with your credentials is very different from the one you are sending when you click on a YouTube video to watch.
All of these contents of the request and also the contents of the response of a server(we shall see in a bit) are not randomly organized.
They follow a certain set of rules and regulations about the structure, type and format of data to be sent and received over the internet. These rules are generally defined as a protocol. And the web works over the HTTP (HyperText Transfer Protocol).
Also there is a secured version of this protocol, HTTPS where the S stands for Secure. This basically encrypts or simply hides the data that is passed between a browser(client) and a server, establishing a more secured form of communication.
I am not going to go at length to describe this protocol, but if you want to know more check out the link here.
Let’s now dive into the second part of our journey, shall we?
2. Reception of Request and Proper Response by The Server:
So we have lifted the curtain upto some extent from the request side, now let’s explore the case how that request is handled in the server computer side, where all the magic happens!
The request in its proper format reaches to the server computer through the internet. There’s so many different and difficult steps involved here, that it would take a whole University course to understand it properly, but we would just assume that the request with all the data, headers and metadata has arrived on the server computer.
The server computer has some code written in some specific languages and frameworks(collection of useful tools that just makes lives easier for the developers) namely: python, node.js, java, c#, PHP. Note that the operation of the server is not limited to these languages, there are others that exist. And we can use these languages for other purposes as well.
The code runs on the server. It receives the request for a particular type of data and parses the request carefully. Then the code serves up the data that was requested by the client or the browser. This data can be anything from some codes about the webpage, or some images or even some other videos.
Like request, response too follows the HTTP protocol to send data and contains metadata and other useful headers too. This is a typical response for an image:
As you can see there is tons of information about the server it was sent from, the date, status of the response, size of the content and even the type of the content that was sent. In this case, we can be ensured from the content-type that an image was sent from the server.
Typically every server sends some HTML code for a request of websites. This is what is looks like:
HTML stands for Hyper Text Markup Language. This is used for creating the structure of the website. As you can see that there are things like <div> and <script> in the HTML code. These are called tags that form up the structure of a website. Every tag has some form of semantic meaning that the browser understands.
So the bottom line is, the server sends the response as desired by the client, whether it is in the form of code or resources such as images or videos. The server itself performs several important activities, such as querying and searching a database, saving information to a database, connecting to other servers for different information and so on, but those are beyond the scope of this article.
Now that we know about response, let’s talk about how the response of the server is handled by the browser or the client.
3. Displaying the webpage:
As we have already seen, the server sends HTML code for typical webpages and sometimes resources as requested by the browser or the client. But how does this work under the hood? How does the browser understand those codes and even understand what to display?
Well I think you already know the answer to that: More Code!!. See Everything in the digital realm as we know it, is shaped by code. Similarly, the browser is written with high performing languages like (C and C++). These languages write all the rules and regulations to understand the code and resources received from the server side. Then the browser displays all those information in the format understandable to us.
CSS defines the aesthetics of the website, more technically how each of the parts of a website would look. What will be shape, colors, font sizes etc.
These codes are stored in some other files that are there on the server. So how does the browser get those codes so that our websites or web applications are prettier and more dynamic?
Well typically the first response that we obtain from the server in the form of HTML codes contain links to those codes that the browser understands. Then the browser uses these links to fetch the required code files and integrate all the codes together to display the websites and web applications that we use in our day to day life.
So now you know there that the magic behind web applications is just some strict set of rules and regulations that have been standardized across the world. Beyond the scope of what we discussed, what we unveiled about how web applications work, there are so many things that come to play in the modern era of web applications. APIs, caching, automation, hosting and cloud services are just some of the prominent ones. We’ll learn about all of those one by one.
The thing about web application and programming, in general, is that you can never learn enough. There’s always going to be something new to explore. It is as Alan J. Perlis said,
There are two ways to write error-free programs; only the third one works.