app flask: wsgi-middleware vs. before_ und after_request()



flask request path (1)

Ich finde es ziemlich verwirrend, was genau die Unterschiede bei der Verwendung von before_request() und / oder after_request() gegenüber der Verwendung einer WSGI-Middleware sind.

Sag, ich möchte etwas sehr albernes machen:

  • Jeder Anfragekörper sollte nach dem Wort "Speck" durchsucht und durch "Eier" ersetzt werden.
  • Nun fragt requests flask-view (nach url-mapping), view-function erzeugt die Antwort
  • Jeder Antwortkörper sollte nach "Eiern" durchsucht und durch "Speck" ersetzt werden

Würde ich eine WSGI-Middleware oder die Flask-Funktionen verwenden? Da ich von Django mit einer sehr robusten Middleware-Suite komme, ist mir der Unterschied nicht klar.

Danke im Voraus. Berni


Answer #1

Eigentlich haben Sie genau die gleiche Wahl in Django. Django basiert teilweise auf WSGI, so dass Sie theoretisch auch WSGI Middleware oder Django Middleware in Django schreiben könnten. Der Grund dafür, dass Sie keine Verwirrung haben, liegt darin, dass die Django-Community Entwickler normalerweise von der WSGI-Middleware abhält. Ein Grund liegt in der Tatsache, dass Django so entworfen wurde, dass es gleichermaßen auf mod_python und WSGI funktioniert. Durch die Verwendung der Django-Middleware funktioniert Ihre Middleware auf beiden Systemen (siehe diesen Beitrag von James Bennett ).

Ein Vorteil beim Erstellen einer WSGI-Middleware besteht darin, dass sie in mehreren Frameworks verwendet werden kann. Beaker ist beispielsweise eine Sitzung und Zwischenspeichern von WSGI-Middleware, die in jedem WSGI-Framework verwendet werden kann. Wenn es speziell in Flask geschrieben wäre, könnten Pyramid-Entwickler es nicht verwenden. Der Maintainer der Bibliothek hat speziell dafür gesorgt, dass die Bibliothek in mehreren Frameworks arbeiten kann, also schrieb er sie als WSGI-Bibliothek.

Grundsätzlich würde ich so meine Entscheidung treffen:

  1. Wenn Sie nur eine Middleware schreiben, die etwas Bestimmtes für Ihre Anwendung tut, verwenden Sie die Middleware Ihres Frameworks.
  2. Wenn Sie glauben, dass Ihre Middleware in einigen Ihrer Apps nützlich ist und anderen Benutzern hilfreich sein kann, sollten Sie immer noch die Middleware Ihres Frameworks verwenden (was Flask wirklich als "Erweiterung" bezeichnet). Siehe Flask-SQLAlchemy als ein Beispiel.
  3. Wenn sich die Leute wirklich für Ihre Middleware interessieren und bereit sind zu helfen, sollten Sie sie in eine WSGI-Middleware-Bibliothek konvertieren, damit sie in anderen Frameworks verwendet werden kann.