Have you ever wondered, things under the hood seems to be more fascinating than the one showcased in front of us.
It's kind of a Butterfly Effect taking place.
So let's pull the shades off and unveil the true story of what's happening behind the scene.
In this bit of a journey, we are going to take a shallow dive in the Django Request-Response Cycle
Seems to be a tedious task for a newbie I must say, Huh! Unfortunately, these are conventional terms and you just can't skip them over twice.
Trying to explain in the easy way possible. But if you don't understand in the beginning, it's okay!
The plot of every story doesn't make much sense in the beginning.
The one who initiates request for services.
WSGI File - Web Server Gateway Interface
This is used to run python applications.
Django: Request-Response model
It contains various elements and files listed below:
This file contains all the configurations of your Django Project.
Middleware is used to perform a function in the application. The functions can be a security, session, csrf protection, authentication etc.
Django views determine what content is displayed on the given page.
URLconfs determine where that content is going.
The model contains the content from the database.
It provides styling for the data and other stuff to be displayed.
If it seems overwhelming right now, trust me it's okay! They were just to leave traces of what's coming next.
Now, let's set the sail of our boat and start off on our little voyage-
The request from the client reaches the Django Server hosted at (
localhost:8000) in case of hosting locally.
It passes through WSGI and reaches the settings.
The very first thing which loads up is settings.py file and in that too Middleware.
Then the request tunnels through the listed middleware for various checks like security, authentication etc.
If the request deems to be okay. It then reaches urls.py file where the requested url is matched with the various urls listed.
Once the url is matched, the request goes to the corresponding view in views.py file.
If the request requires some information to be rendered from the database, then views talks to the database via models.
Information from database is collected.
Now the template will be rendered for styling to the views.py file and if the template does not exist, it raises an exception (
page not found)
The HTTP response object is rendered into a string as object leaves the Django app.
Finally your web browser render it into a beautiful web page.
This eleven pointer explaination concludes the request-response journey and now it's time to set down the sail and attempt docking.
In a nutshell, that's what happening under Django's Hood!
Diving deeper is not possible because you and I are in a boat, remember!
But if you are interested in more technical and detailed stuff. You can refer to Mozilla, it has a huge developer community.
To know about the journey between client and web server, check How does the web works.
You can also share your feedback in the comment section below.
p.s: what next?