Skip to content


Micro-framework initialization problem

Micro-framework-based projects are clean while they're small. Every micro-framework codebase I've seen, has a mess in the project initialization. With time, create_app() becomes filled with ad-hoc settings, imports-within-functions, and plug-in initializations.

The Application Factory Pattern, proposed, for example, in the official Flask documentation, and the Flask Mega-Tutorial, legitimize this approach.

The nature of create_app() leaves no place for the open-closed principle. We update this module every time we add a new plug-in, a new blueprint, or a new package.

# myproject/
# A common Flask application. The code is based on the Flask Mega-Tutorial.

def create_app(config_class=Config):
    app = Flask(__name__)

    migrate.init_app(app, db)

    from myproject.errors import bp as errors_bp

    from myproject.auth import bp as auth_bp
    app.register_blueprint(auth_bp, url_prefix='/auth')

    return app

A common Flask application. The code is based on the Flask Mega-Tutorial.

With deescovery, you can make the same code shorter, and remove the dependencies from implementation details.

# file: myproject/
from flask import Flask
from deescovery import discover
from deescovery.flask import get_flask_rules

def create_app():
    flask_app = Flask(__name__)
    discover("myproject", get_flask_rules("myproject", flask_app))
    return flask_app

Initially designed to solve a specific problem of initializing Flask applications, it was made generic enough to work with any micro-framework or no framework at all.