Django’s response cycle — Life of a web request
When a user enters the URL in browser a web page is shown in the browser window. So how does this determine which web page should be displayed? To explain this we need to know the concept of the request-response cycle. As we are focusing on the Django MVT architecture, we will look into how the request-response cycle works in Django. The following diagram shows how a request is processed in each step and its corresponding response is made.
What is a request?
Whenever we type in the URL in the browser or in the tool like Postman, it will be converted to a web request. The web request is generated by considering few things taking in mind like,
- Protocol : Two different protocols are available for a web request, Http and Https.
- IP/Domain name : A unique identifier which is used in order to identify where the resource is located if request comes. Sometimes this domain can also be associated with a subdomain.
- Path : A URL path which is used to specify a particular page, file or location.
The request is an information packet created considering the URL parts, which is then used to access the resource on server. After analysing a request, its corresponding result is generated as a response. A request can be an API request too in which the response would be shown in different formats of JSON, XML, text…
Request server communication
So after creating a request it needs to be communicated with server. This is where Nginx, Apache etc… comes into action. So whenever a request is created it would be taken by one of the web servers that we use, in our case its Nginx. Nginx will pass this request by looking in the rules specified in the nginx config to a web server gateway interface known as wsgi. Using wsgi, nginx communicates with the Django application.
WSGI is a specification which says how a web server and web application should be communicated. WSGI will be implemented using the gunicorn package if it is synchronous server, and for asynchronous server we will be using ASGI and for implementation we will be using the uvicorn. For now we will look in the case of WSGI.
What happens after a request is received by the Django application?
In Django when a request is received first it will be passed through a middleware section. This can be considered as the gateway of the Django application. Like a door to your home, we only allow those people who we know right? Likewise, Django accepts only those requests which are safe to be accepted.
The default middleware in Django is mentioned below. It is also possible to create a custom middleware.
MIDDLEWARE = [
'django.middleware.security.SecurityMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
]The request data contains the URL path which is then pattern matched with router section of Django’s urls.py and once a matching pattern is obtained its corresponding function is loaded. This function will be written in the views.py file.
The view function which is in views.py is where we write the business logic for the web app. This business logic will be executed and it would return a response. In this view function it would also connect to the database in order to fetch or store the desired data. This is done using the ORM(Object Relational Mapping) methodology which instead of using traditional query make use of ORM commands and syntax. In the ORM methodology every table is considered as instance of class and each fields can be accessed by creating object for that particular instance which makes it OOPs friendly. The response of a view function can be http response.
Back to user as Response
A view will be connected to particular template where our processed information is to be displayed. In general, this template would be a html file with necessary static files. Once everything is completed the response with necessary data is generated and it will again pass through all the layers in which the request came in but in reverse order. So once responce is completely generated by Django application it would be passed to middleware then to the WSGI and through Nginx it would be available in the web browser where the request originated from.
