The Relicans

loading...

The flow of a request in Django

Fabrícia Diniz
・3 min read

A while ago I was a beginner developer, and for those like me who don't have a computer science/engineering background it can be very difficult to understand what's going on behind the curtains when we develop a web application. For those who are just starting out in the world of programming with Python and Django and who are perhaps feeling overwhelmed and lost with what happens in web applications, I'm going to explain how I managed to understand the flow of the thing.

The request

Considering a complete application, the flow starts when you type an url in the browser. From there Django goes into your settings.py file and looks for the ROOT_URLCONF variable to find out in which file the url patterns "known" to your application are in. Knowing which file to look for urls in, Django then searches for the urlpatterns variable in that file, which contains all the base urls your application recognizes. I say base urls because this file usually link to other url files that contain the most detailed routes.

urls.py

Knowing which file is the right one, Django goes through all the url patterns in order and looks for one that matches the url typed in the browser. Once there is a match it will import and call the associated view. In other languages, the "view" is called a controller because it controls how the information in the application is treated and sent to the browser / user. This can get a little confusing when studying the MVC (Model-View-Controller) pattern, where view means the part the user interacts with.

If none of the urls in the list match, Django returns an exception indicating that it couldn't find any urls that matched the url entered by the user. Often an error occur simply because you forgot to add a specific url to your url file. This can happen even with the most experienced developers.

View

Well, back to our flow in Django, when the view is called an HttpRequest object is passed to it with information regarding the request that was made. This object contains the url called and can contain various other information such as: arguments passed through the request body, user session data... Information that will be used by the view to decide what information will be returned to the user. This is where the bulk of the programming will happen, where you will be able to access the database to fetch information, manipulate incoming data, and do all the magic of your program.

Template

After all the magic and all the manipulation happens, it's time to return the information to the user. A view can contain several methods that handle different requests for that url (if it's a GET or a POST, for example) and in the end the methods must return both the data and which html file (template) should be rendered when displaying the information for the user. This can happen in several ways, Django can even handle your requests on its own, without you having to code all the behavior. You'll have to do some research to see which way works best for you, and I might even post about that in the future.

Success!!

Once the view returns the information and which html file should be rendered, Django will show that page to the user and then (if everything is done correctly) it's a win!!

I hope you were able to understand the flow of a request in Django, but feel free to comment with your questions if you didn't understand, every question is valid.

Discussion (0)