官术网_书友最值得收藏!

Signals

Flask integrates with Blinker (https://pythonhosted.org/blinker/), which is a signal library that lets you subscribe a function to an event.

Events are instances of the blinker.signal class created with a unique label, and Flask instantiates ten of them in 0.12. Flask triggers signals at critical moments during the processing of a request. Refer to http://flask.pocoo.org/docs/latest/api/#core-signals-list for the full list.

Registering to a particular event is done by calling the signal's connect method. Signals are triggered when some code calls the signal's send method. The send method accepts extra arguments to pass data to all the registered functions.

In the following example, we register the finished function to the request_finished signal. That function will receive the response object:

    from flask import Flask, jsonify, g, request_finished 
from flask.signals import signals_available

if not signals_available:
raise RuntimeError("pip install blinker")

app = Flask(__name__)

def finished(sender, response, **extra):
print('About to send a Response')
print(response)

request_finished.connect(finished)

@app.route('/api')
def my_microservice():
return jsonify({'Hello': 'World'})

if __name__ == '__main__':
app.run()

Notice that the signal feature will only work if you install Blinker, which is not installed by default as a dependency when you install Flask.

Some signals implemented in Flask are not useful in microservices, such as the ones occurring when the framework renders a template. But there are some interesting signals that Flask triggers throughout the request life, which can be used to log what's going on

For instance, the got_request_exception signal is triggered when an exception occurs before the framework does something with it. That's how Sentry's (https://sentry.io) Python client (Raven) hooks itself onto Flask to log exceptions.

It can also be interesting to implement custom signals in your apps when you want to trigger some of your features with events and decouple the code.

For example, if your microservice produces PDF reports, and you want to have the reports cryptographically signed, you could trigger a report_ready signal, and have a signer register to that event.

One important aspect of the Blinker implementation is that all registered functions are called in no particular order and synchronously on the signal.send calls. So, if your application starts to use a lot of signals, all the triggering could become an important part of the time spent processing a request, and create bottlenecks.

If you need to do work that doesn't impact the response, consider using a queue like RabbitMQ (https://www.rabbitmq.com/) to queue up the task and have a separate service do that work.

主站蜘蛛池模板: 玉环县| 商水县| 北碚区| 石楼县| 遵化市| 文安县| 广德县| 清河县| 玉屏| 拜泉县| 曲阳县| 大关县| 嵩明县| 正蓝旗| 松潘县| 兰溪市| 杂多县| 兰溪市| 保康县| 平陆县| 秭归县| 彭州市| 黄骅市| 海安县| 屯门区| 东丰县| 郸城县| 达孜县| 榆树市| 文成县| 连云港市| 衡阳市| 石渠县| 韶关市| 涡阳县| 利津县| 青岛市| 通化市| 连南| 民勤县| 比如县|