: wsgi-middleware vs before_ e after_request()

Question

Trovo abbastanza confuso quali siano esattamente le differenze nell'uso di Flask before_request() e/o after_request() rispetto all'utilizzo di un middleware WSGI.

dire che voglio fare qualcosa di molto stupido come questo:

• Ogni richiesta-corpo deve essere sottoposto a scansione per la parola "pancetta" e sostituirlo con "uova".
• richiesta Ora colpisce pallone-view (secondo url-mapping), vista-funzione crea la risposta
• Ogni risposta-corpo deve essere analizzato per "uova" e sostituito con "pancetta"

Would Utilizzo un middleware WSGI o le funzioni Flask? Venendo da Django con una suite middleware molto robusta, la differenza non mi è chiara.

Grazie in anticipo. berni

Answer 1

In realtà, hai la stessa scelta in Django. Django, in qualche parte, è costruito su WSGI, quindi potresti teoricamente scrivere anche il middleware WSGI o il middleware Django in Django. Il motivo per cui non si confonde è perché la comunità Django di solito allontana gli sviluppatori dal middleware WSGI. Una ragione è dovuta al fatto che Django è stato progettato per funzionare allo stesso modo su mod_python e WSGI. Utilizzando il middleware Django, il middleware funziona su entrambi i sistemi (vedere this post by James Bennett).

Un vantaggio che la creazione di un middleware WSGI è che può essere utilizzato in più framework. Ad esempio, Beaker è un middleware WSGI di sessione e memorizzazione nella cache che potrebbe essere utilizzato in qualsiasi framework WSGI. Se fosse stato scritto specificamente in Flask, gli sviluppatori Pyramid non potevano usarlo. Il manutentore della libreria ha fatto in modo che la libreria potesse funzionare in più framework, quindi l'ha scritta come libreria WSGI.

In sostanza, questo è il modo vorrei fare la mia decisione:

1. Se sono solo scrivendo un middleware che fa qualcosa di specifico per l'applicazione, utilizzare il middleware del quadro.
2. Se pensate che il vostro middleware sia utile in alcune delle vostre app, e potrebbe essere utile per altre persone, usate comunque il middleware del vostro framework (che Flask chiamerebbe in realtà una "estensione"). Vedere Flask-SQLAlchemy come esempio.
3. Se le persone si interessano veramente al middleware e sono disponibili ad aiutarlo, pensa di convertirlo in una libreria middleware WSGI in modo che possa essere utilizzata in altri framework.