Understanding The Request-Response Lifecycle In Django¶
Let's start understanding the request-response lifecycle of a Django application. Every web application uses HTTP/HTTPS protocol. In the HTTP/HTTPS protocol client sends a request to the server based on the request data server sends the response back to the client. It's the basic principle of HTTP protocol. While setting up the django application in the server we need a webserver and wsgi server. Webserver helps us in serving static files/content. If we did not use the webserver to serve static files then it has to served by WSGI server which results in more number of requests to the server. So, gradually it slow down the application performance. Web server balances the requests load on the server. So, it's highly recommended to use the webserver.
A client can be defined as a piece of software which can send a request by following the HTTP/HTTPS protocol. In general we consider client as a Web Browser. While deploying the django application on the server we use one of the combinations of a "Nginx, uWSGI and Django" or "Nginx, gunicorn and Django" or "Apache, mod_wsgi and Nginx". As of now, we will discuss the deployment process but we discuss about request-response lifecycle of Django application. We will be discussing on when a request comes in how it can be processed and how the response will be created and sent back to the client.
When a client sends a request to the server it first passed to the webserver, It contains the configuration rules to dispatch the request to the WSGI server or served by itself. WSGI server pass the request to the Django application. Django has the following layers in dealing with request-response lifecycle of a Django application.
Layers of Django Application¶
- Request Middlewares
- URL Router(URL Dispatcher)
- Views
- Context Processors
- Template Renderers
- Response Middlewares
Whenever the request comes in it is handled by the Request middlewares. We can have multiple middlewares. we can find it in project settings(settings.py). Django request middlewares follows the order while processing the request. Suppose if we have request middlewares in the order A, B, C then the request first processed by the middleware A and then B and then C. Django comes up with bunch of default middlewares. We can also write our own or custom middlewares. After request processed by the middlewares it will be submitted to the URL Router or URL dispatcher.
URL Router will take the request from the request middleware and it takes the URL Path from the request. Based on the url path URL router will tries to match the request path with the available URL patterns. These URL patterns are in the form of regular expressions. After matching the URL path with available URL patterns the request will be submitted to the View which is associated with the URL.
Now, we are in business logic layer Views. Views processes the business logic using request and request data(data sent in GET, POST, etc). After processing the request in the view the request is sent context processors, by using the request context processors adds the context data that will help Template Renderers to render the template to generate the HTTP response.
Again the request will send back to the Response middlewares to process it. Response middlewares will process the request and adds or modifies the header information/body information before sending it back to the client(Browser). After the browser will process and display it to the end user.
References:
https://docs.djangoproject.com/en/2.0/topics/http/middleware/
https://docs.djangoproject.com/en/2.0/ref/request-response/
Related Blog Articles
Getting Started With Django First App
Lets get started with django first app. I always recommend newbies to use the latest versions of django and python.
Understanding Of Http Protocol
Before talking about HTTP Protocol, lets talk about "Protocol". A protocol is a set rules to be followed to communicate with one another.