Request response lifecycle

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 HTTP/HTTPS protocol client sends a request to the server and 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.

  • Webserver 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

  1. Request Middlewares
  2. URL Router or URL Dispatcher
  3. Views
  4. Context Processors
  5. Template Renderers
  6. Response Middlewares

Request 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.

URL Dispatcher

  • 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.

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

Context Processors

  • Request context processors adds the additional context data as defined.
  • The context used by renderers to render the template to generate the HTTP response.

Template Renderers

  • Template renderers uses the context generates the response.
  • The response content can be xml, html, json, etc.

Response Middlewares

  • 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(i.e Browser).
  • Client or Browser recieves the response and shows it to the user.

References: