In this Django Bits series, I will explore different concepts of Django. First, I will begin with how Django works and the flow of a user request.
I will create videos (Go to the bottom) for this where I draw, explain, and show examples, but also a written blog post about the subject as well.
The flow of a user request in Django
When a user opens up a website in their browser, the first request goes to your web server. This can typically be Nginx, Gunicorn, Apache, etc. There are a lot of them to choose between. I generally use a mix between Gunicorn and Nginx.
When the request hits the web server, the web server points to (typically at least) your wsgi.py file. This is entry points for the web server, and this is where the Django app is activated/created.
Inside the wsgi.py file, you can see that it loads the settings.py. This is the next step. It might be a bit misleading writing this, because often does for example Gunicorn use the manage.py to start and use the settings.py file (and from there, load the wsgi.py file).
Anyways, inside the settings.py file, you will see that we load the urls.py file from the main Django app. Inside here, the request from the web server, will find a matching route/path. And this path will forward the user to the correct view.
When the view has been loaded by Django, a template will be rendered. But before it's rendered, we typically get some data from the database and similar.
When the template is being rendered, the user sees the result in the browser. And that is generally how the flow is.
The flow can on the other hand be a bit more complicated. For example, inside the settings.py file, you will see a list of middlewares. This is code that Django will execute during the request. Here, Django will take care of security, sessions, and similar.