Django is a web framework. Sounds fancy, right? But let’s be honest, when you first hear that phrase, it doesn’t really mean much. What exactly is a framework? And what does it mean that Django is for the web?
Before you can appreciate what Django gives you, you need to understand what actually happens when you open a browser and type something like:
www.example.com
Think of it like sending a letter. You write the address on the envelope, drop it in the mailbox, and somehow, like magic, it arrives at the right house. The internet works in almost the same way.
When you type a web address into your browser, you’re essentially writing a digital address on an envelope. Behind the scenes, a whole system makes sure your request finds the right destination almost instantly.
In this article, I’m going to walk you through the journey of a request:
- How a browser knows where to go.
- How the internet finds the right server.
- How your request gets translated into something a web app (like Django) can understand.
- And finally, how Django receives the request, does the necessary work, and sends a response back.
Think of this article as a map of the plumbing of the web. By the time we’re done, you’ll understand how information flows, from your keyboard strokes in the browser bar, all the way to Django running on a server and responding with the page you see.
How the Web Works
When you hit Enter in your browser to visit www.example.com, a whole chain of events kicks off. Tiny, invisible steps (happening in milliseconds) connect you to the right server, fetch the right information, and display it neatly on your screen.
To understand how a request reaches a server, we’ll focus on two major steps:
- DNS (Domain Name System)
- HTTP (Hypertext Transfer Protocol)
What is DNS (Domain Name System)?
Every computer connected to the internet can be reached using a network number called an IP address. Maybe you’ve seen some of these before:
- 127.0.0.1 — the address your computer uses for itself (on its internal network).
- 192.0.2.172 — an example of a public IP address that makes a computer reachable on the internet.
Computers love numbers. But for humans? Remembering long strings of numbers is not fun. That’s where the Domain Name System (DNS) comes in.
DNS is like the Internet’s phonebook. When you type a website address (like example.com) into your browser, DNS translates that human-friendly name into the actual IP address of the server hosting the site.
The Structure of Domain Names
A domain name has a simple structure, made of several parts separated by dots and read from right to left.
Take our example: www.example.com
- .com → This is the Top-Level Domain (TLD). TLDs are carefully managed by an organization called ICANN. You’ve probably also seen others like .org, .net, .dev, or country codes like .ke (Kenya) or .uk (United Kingdom).
- example → This is the domain name. It’s the unique identity of a service on the internet, the part users are most likely to recognize.
- www → This considered the subdomain of a domain. A domain might have many of these, like www, m, mail, wiki, or whatever a domain owner might want to name them. Subdomains can also be more than one level deep, so a.b.example.com is valid, and a is a subdomain of b.example.com and b is a subdomain of example.com.
So far, we’ve seen how the internet uses DNS like a massive phonebook (or a global postal system) to turn human-friendly addresses like example.com into the exact IP address of the server you want to reach. Without DNS, you’d be stuck memorizing numbers instead of names, and the web would feel a lot less human.
But finding the right server is just the beginning. Once your browser knows where to go, the next big question is: how do the browser and server actually talk to each other? That’s where HTTP comes in the language of the web.
Next, we’ll follow the request a little further and see how your browser and Django exchange messages, step by step.
HTTP — The Language of the Web
We saw how DNS acts like the internet’s phonebook, helping your browser find the exact server behind a domain name. But once your browser has the server’s address, another question pops up:
How do the browser and server actually talk to each other?
That’s where HTTP (Hypertext Transfer Protocol) comes in. If DNS is the postal system that makes sure your letter reaches the right house, HTTP is the language you and the house’s owner use when you start a conversation at the door.
What is HTTP?
HTTP is the protocol of communication between browsers (clients) and servers. It defines the rules for:
- How a request should be written.
- How a server should respond.
- What happens if something goes wrong?
Every time you visit a website, your browser is quietly saying something like:
“Hey server, I’d like the homepage, please.”
And the server responds:
“Here you go, HTML, CSS, images, and everything you need to display the page.”
This back-and-forth happens in milliseconds, but it’s the foundation of how the web works.
The Anatomy of an HTTP Request
When your browser asks for a page, it doesn’t just shout “give me stuff!” The request is structured, like a well-written letter. It usually has three main parts:
- Request Line Example: GET /about/ HTTP/1.1
This tells the server what you want (GET means “fetch something,” /about/ means a path to a particular resource on a site).
- Headers
Think of these as little notes with extra info.
Example: User-Agent: Chrome/120 (so the server knows the type of browser making the request).
- Body (sometimes)
For requests such as submitting a form, the actual data (e.g., your username/password) should be entered here.
The Anatomy of an HTTP Response
Once the server understands your request, it replies with a structured response. Again, three main parts:
- Status Line
Example: 200 OK → Everything went fine.
Or 404 Not Found → Page doesn’t exist.
Or 500 Internal Server Error → Something broke on the server side.
- Headers
Extra info for the browser, like how long to cache the response or what type of file it is.
- Body
This is the actual content, HTML, JSON, an image, or whatever the browser asked for.
When the Request Finally Reaches Django
Alright, we’ve talked about browsers, DNS, and HTTP. We know how a request leaves the browser, finds the right server, and arrives at its destination.
Now the spotlight is on Django. This is where the real action begins. Django’s job is simple at first glance: take an incoming HTTP request and return an HTTP response.
That response could be a web page, JSON data for an API, or even a file download. But before Django can step in, there’s one last hurdle to clear: the Python web server.
The Python Web Server
When people say “web server,” they might mean two things:
- the machine running the software, or
- the software itself that listens for requests.
Here, we’re talking about the software.
The web server is the first piece of software to actually *hear * the HTTP request when it arrives at the server. Its job is to pass that raw HTTP request into a format Django can understand.
In Python, there is a format called WSGI (Web Server Gateway Interface). WSGI is used so that any web server(Gunicorn, uWSGI, or mod_wsgi) can speak to any Python web framework. Without Python's standard WSGI, every web server would need a custom way of talking to every framework.
Once the request is handed off by the server through WSGI, Django steps in. This is where your work as a Django developer really matters.
Your job is to:
- Tell Django which URLs it should listen for.
- Write the views that decide what happens when those URLs are requested.
From there, Django builds the response, whether that’s rendering an HTML template, returning JSON data, or redirecting the user somewhere else.
In the next blog, we will talk about:
- how to Set Up Django
- how to declare the URLs.
- how to group sets of related URLs.
- how to extract information from URLs that can be used by the code that returns responses.
Top comments (0)