Excellent rant. I have noticed the exact same problems with PSGI middleware. People end up with apps that depend on middleware that then depend on the app. This serves two purposes: making for a nice blog post about how generic you are (just implement these eight functions inside your app!), and adding bugs.
Just treat web programming like normal programming, and everything becomes simple!
I haven't done anything other than dabble with python in years and have never used WSGI, can someone point me to examples of this 'abuse' of WSGI in the wild? I'd love to get more background so I can really understand this post.
the author's argument is essentially that you shouldn't reach out to middleware from within your application code (e.g. sessions), but that such functionality should be provided by a non-middleware API, because you should be able to swap in/out middleware without any change to your app code.
Middleware can be effective for certain cross cutting situations (csrf checking and database transaction handling come to mind), but I think it's been applied to too many problems where it was completely unnecessary.
For example, user authentication in most web apps needs to be dealt with at the application level. Middleware based approaches like AuthKit and repoze.who end up relying on weird hacks to communicate between the authentication middleware and the application layer.I'm really not a fan of shuffling important application level data through random environment variables. Not to mention they're a massive pain in the ass to configure.
Note that for both csrf checking and database transaction handling, you still need hooks in place at your application level to be able to disable csrf checks or transactions in certain application specific situations, so it's not like you can just throw it into the middleware layer and forget about it.
I think Beaker has been the Python standard for a while now (at least in non Django land). I would also recommend checking out Werkzeug in general, although its scope is a bit different than Beaker.
Most modern JavaScript toolkits send an "X-Requested-With: XMLHttpRequest" HTTP header; these requests are detected and automatically not handled by this [CSRF] middleware. We can do this safely because, in the context of a browser, the header can only be added by using XMLHttpRequest, and browsers already implement a same-domain policy for XMLHttpRequest.
- profiling - caching - csrf protection
This is what I think wsgi middleware should be.