This may ease some pain points when adding new apps.
I don’t think this is a good idea. I think you’re going to create more “pain points” by doing this than you are going to fix.
-
Middleware, by definition, applies to every request being handled. I would think it would be more confusing to define middleware within an app by potentially creating the impression that the middleware only applies to that app.
-
You’d be creating a situation where developers need to check every installed app for middleware being applied when trying to diagnose issues.
-
You’d be creating a potential situation where two systems behave differently based upon the presence or absence of an app, in areas of the code that do not (or should not) be affected by that app.
-
Middleware is sequence dependent - any specific middleware class may be sensitive to the order in which it is defined. How are you going to be able to manage that if you have multiple apps each defining middleware?
Middleware is global, I think the only appropriate place for defining it is in the global environment.
All good points. But,
4. Middleware is sequence dependent - any specific middleware class *may* be sensitive to the order in which it is defined. How are you going to be able to manage that if you have multiple apps each defining middleware?
Processed in the order they are listed in INSTALLED_APPS
2. You’d be creating a situation where developers need to check every installed app for middleware being applied when trying to diagnose issues.
The code lives inside the app even now. It is only the listing that is in settings.py. Debugging middleware code requires getting to the app code even now.
3. You’d be creating a potential situation where two systems behave differently based upon the presence or absence of an app, in areas of the code that do not (or should not) be affected by that app.
Can you explain this more? Even now two systems behave differently upon the presence or absense of an app.
But that has other implications as well (e.g. url and template override resolution) Adding yet another sequence dependency increases the chances of creating a non-reconcilable conflict.
Yes - but at least you know which apps to check because you have a single place to look for the middleware index.
It’s a lot easier to find the list in settings than to search through 20-30 apps counting both your project apps and third-party apps you may have installed.
The key phrase here is:
Not every app affects every operation in other apps. And, many apps don’t affect other apps at all. You can’t make that assertion about middleware.
I fail to see how adding one line in settings creates more pain points - especially since you can write code to conditionally modify your middleware in your settings file to alter that list based upon your installed apps, if you really need it to do so.
When adding a new app, I would like to add it to INSTALLED_APPS and keep going.
That would be the best user experience in my opinion.
Most well behaved apps should be able to support this type of configuration.
That’s fine - I can appreciate that opinion.
However, architectually, it’s a bad idea.
Middleware is not “app specific”. Middleware is a global issue, and no desire to “simplify” things is going to change that.
Most middleware I have seen are primarily for the purpose of solving a particular app’s requirement. Some apps provide a middleware as a service for other apps that depend on them.
Can you give an example of a middleware that is outside of these two?
I understand that middleware has to be frozen before the request/response cycle begins but does that preclude it from being decentralized?
Sure - all of them that are provided by Django itself.
Also, Django Debug Toolbar
Also, our SNMP middleware that tracks performance metrics
Also, django-login-required-middleware · PyPI
Again, all global operations.
You’ve yet to make a case that there’s any value in doing so other than you only want to edit one line instead of two.