Blog post: "Django 6.0 Internals: The Startup Process"

[agile jasper]

I wrote a short post about "internals" of Django - specifically how the framework startup process works under the hood. It covers topics like wsgi, apps registry and lazy settings loading.

I tried to keep the post approachable by anyone regardless of their experience level, so I made some simplifications, but still made sure to not oversimplify the actual mechanics too much.

Would love feedback, corrections, questions or any other kind of discussion around the topic.

Link: https://medium.com/@gdbxcvgg/django-6-0-startup-process-1ddadabe672c

[marble salmon]

This is a nice blog post. I haven't worked through this process, but it definitely helped me understand it better.

It executes the prebuilt middleware chain, resolves the URL, calls the view and returns the response.

Does it really evaluate the middleware before resolving the URL to a view? I would have expected a request that isn't captured in the urls.py would not execute the middleware.

[agile jasper]

Yeah it does. 404 Not Found is still a response that needs to be processed. And also Django's CommonMiddleware is responsible for appending the slash ("/") at the end of URL in the case of url resolution fail, but only if APPEND_SLASH=True is set in settings.

I didn't want to get too deep into middlewares in this post, because I think that they belong more to the request/response lifecycle which I also want to write about.

[twin girder]

Does it not technically go through the middlewares twice? On on the way .... down, and one on the return when the response has been created?

[agile jasper]

As far as I know, it can even run more than twice. The best mental model for Django middlewares is onion-like structure. When you have in settings:

MIDDLEWARE = [
  'A',
  'B',
  'C',
]

its called in that order: A -> B -> C -> view -> C -> B -> A.

However, as Django Docs specify, there could be also methods like process_view in middleware which runs directly before executing view. Also there are process_template_response and process_exception which also can be called depending on the context.