Request/Response Cycle of Django – Basic

Django is a popular framework that is used by many high level tech companies for back-end development. Django has lots of handy structure to handle web applications. One of them is request/response cycle of django that we will cover today. As a developer understanding the request/response cycle gives you more efficient control on your Django app, actually on your all web apps.

Request and response are fundamentals of basic web applications. They are actually two points that have cycle between them. While request is starting-point, response is ending-point of process. When a user who wants to use your app, our app uses this cycle in order to give response to user. There are structures, parts and middlewares that in the cycle handle your request object, modify request data, coupling with business logic and creates new response object. Response object also go through cycle and raises across the user.

Request/Response Cycle of Django

Client raises request

Request arises when user wants to use app. We call it as “client“. Client sends request to our app. This request might include some data, parameters and logical information.

Web server greets request

A client sent request to our app and web server that runs our app greets request. It receives request and sends to connector that might be called WSGI between framework and web server.

WSGI handles request

Web servers do not know frameworks and frameworks do not web server too, so we need to have connector between them. WSGI handles request and converts to format that framework is able to understand. Request with all its extra data and information lands to framework.

Request Middlewares

Middlewares are important of the cycle because you can interfere a request before your specific business logic parts. All request goes through middlewares and meanwhile you can mutate request by your requests. Authentication control, formatting are some examples of middlewares.

URL Resolution

Requests might come to our app but we need to know they are related which business logic, so our app has different urls (paths and routers). Each url has own business logic function and each url is separate between. To illustrate, to authentication user with your app, your front-end app requests your app’s https://api.ahmetonursolmaz.com.tr/auth point and our app can understand request’s purpose and send it to specific business logic part of app. After middlewares mutated our request and now request should go to where it belongs. 🤣 URL resolution enables us to redirect request to views.

Views

Views are business logic part of your app. You can do everything that you want related with your logic. You can connect your databases, insert data there or retrieve data from there. In short, you can do everything for your specific purpose. After your transaction on request, in this part we need to create response object that we can use. Request object dead and now we have response object. This response object has two different type. One of them is success and another one is exception (fail). Success response goes to global middlewares directly but exception responses go to its specific middlewares. After exception goes through middlewares that are for fail status, also it goes to global middlewares.

Response Middlewares

Our view has prepared response object but we need to make sure response is ready to raise to user. Like all requests goes through request middlewares, all responses also go through response middlewares and you can mutate all responses globally there. We can return standart format to user.

Again, WSGI

Our framework handled request and created new response object, After all, our framework’s job is over and time to convert it to format that web server understand. Like start-point, at the moment WSGI converts our response object to web server’s format.

Web server returns response

Our response is ready for user 🥳 and web server returns it to user with HTTP. User can see request’s detail and response data.

We have covered all request/response cycle of django framework in basic level without using advanced terms. That one is fully proper for starting level and we are going to go through this topic in advanced level. You can subscribe to our articles to follow series. Thanks for all you reading and good to develop something everyone!