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.