matraz: wsgi-middleware vs before_ y after_request()

Question

Me resulta bastante confuso cuáles son exactamente las diferencias en el uso de before_request() y after_request() de Flask versus el uso de un middleware WSGI.

decir que quiero hacer algo muy tonto como esto:

• Cada petición de cuerpo debe ser escaneado para la palabra "tocino" y ser reemplazado con "huevos".
• solicitud Ahora golpea matraz de vista (de acuerdo con la url de mapeo), vista en función crea la respuesta
• Cada respuesta de cuerpo debe ser escaneado para "huevos" y se sustituye por "tocino"

Would Uso un middleware WSGI o las funciones de Flask? Viniendo de django con un conjunto de middleware muy robusto, la diferencia no está clara para mí.

Gracias de antemano. berni

Answer 1

En realidad, usted tiene exactamente la misma opción en Django. Django, en alguna parte, se basa en WSGI, por lo que teóricamente podrías escribir middleware WSGI o middleware de Django en Django también. La razón por la que no hay confusión es porque la comunidad de Django generalmente aleja a los desarrolladores del middleware de WSGI. Una razón se debe al hecho de que Django fue diseñado para funcionar igualmente en mod_python y WSGI. Al utilizar el middleware Django, su middleware funciona en ambos sistemas (consulte this post by James Bennett).

Una ventaja que tiene la creación de un middleware WSGI es que se puede usar en múltiples marcos. Por ejemplo, Beaker es una sesión y almacenamiento en caché de middleware de WSGI que podría utilizarse en cualquier marco WSGI. Si fue escrito específicamente en Flask, los desarrolladores de Pyramid no podrían usarlo. El mantenedor de la biblioteca se aseguró específicamente de que la biblioteca pudiera funcionar en múltiples marcos, por lo que la escribió como una biblioteca de WSGI.

Básicamente, se trata de cómo iba a tomar mi decisión:

1. Si se acaba escribiendo un middleware que hace algo específico para su aplicación, utilice el software intermedio de su marco.
2. Si cree que su middleware es útil en algunas de sus aplicaciones y puede ser útil para otras personas, siga utilizando el middleware de su marco (lo que Flask realmente llamaría una "extensión"). Ver Flask-SQLAlchemy como un ejemplo.
3. Si la gente está realmente interesada en su middleware, y está dispuesta a ayudar, piense en convertirla en una biblioteca de middleware de WSGI para que pueda ser utilizada en otros marcos.