

WSGI Middleware Considered Harmful - joubert
http://dirtsimple.org/2007/02/wsgi-middleware-considered-harmful.html

======
zepolen
Imho there is Pure and Unpure WSGI middleware, the former can be used or
removed with _zero_ change to the application, this works for things like:

\- profiling \- caching \- csrf protection

This is what I think wsgi middleware _should_ be.

------
jrockway
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!

------
spooneybarger
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.

~~~
joubert
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.

~~~
spooneybarger
are there examples of WSGI applications that provide sessions as middleware?
just curious to see the approach in action.

~~~
joubert
I found Beaker, which looks pretty nice.
<http://beaker.groovie.org/index.html>

------
joubert
this was written early 2007. do you guys / girls agree with the author?

~~~
stevenwei
I still agree.

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.

~~~
joubert
Do you have a recommended session-handling API for a WSGI-based app (I'm not a
framework such as Django)?

I'm currently looking at Beaker (<http://beaker.groovie.org/index.html>) but
it is a middleware-based approach.

~~~
stevenwei
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.

