Current implementation is using Flask events to handle requests at the beggining and end of processing.
The alternative solution is to make it a Flask extension that adds itself as middleware wrapper around Flask application and process requests and responses outside flask context.
Advantages are:
- No interaction with flask means less complexity
- Logging of the requests as
werkzeug does is not so effective inside Flask. after_request which holds the response object is not executed on exception and log event of errors may be lost
- Probably the log of requests, does not need to be repeated and a simple filter and formatter on the logger of
werkzeug is enought to fix the problem
Dissadvantages:
- Need to rewrite current implementation
Current implementation is using Flask events to handle requests at the beggining and end of processing.
The alternative solution is to make it a Flask extension that adds itself as middleware wrapper around Flask application and process requests and responses outside flask context.
Advantages are:
werkzeugdoes is not so effective inside Flask.after_requestwhich holds the response object is not executed on exception and log event of errors may be lostwerkzeugis enought to fix the problemDissadvantages: