The application factory pattern helps you create Flask apps in a clean way. It lets you make multiple app instances with different settings easily.
Application factory pattern preview in Flask
def create_app(config_name=None): app = Flask(__name__) if config_name: app.config.from_object(config_name) # Initialize extensions here # Register blueprints here return app
The function create_app returns a new Flask app instance.
You can pass configuration names or objects to customize the app.
def create_app(): app = Flask(__name__) return app
def create_app(config_name): app = Flask(__name__) app.config.from_object(config_name) return app
def create_app(): app = Flask(__name__) from .extensions import db db.init_app(app) from .routes import main app.register_blueprint(main) return app
This example shows a simple Flask app using the application factory pattern. It creates the app inside create_app, registers a blueprint with a home route, and runs the app.
from flask import Flask, Blueprint main = Blueprint('main', __name__) @main.route('/') def home(): return 'Hello from the factory app!' def create_app(): app = Flask(__name__) app.register_blueprint(main) return app if __name__ == '__main__': app = create_app() app.run(debug=True)
Use the factory pattern to keep your app flexible and testable.
Register extensions and blueprints inside the factory function.
Do not create the app globally; always create it inside the factory.
The application factory pattern creates Flask apps inside a function.
This helps with configuration, testing, and organizing code.
Use it to register extensions and blueprints cleanly.
Practice
application factory pattern in Flask?Solution
Step 1: Understand the pattern's purpose
The application factory pattern creates the Flask app inside a function instead of a global variable.Step 2: Benefits of this approach
This allows flexible configuration, easier testing, and clean registration of extensions and blueprints.Final Answer:
To create the Flask app inside a function for better configuration and testing -> Option DQuick Check:
Application factory = create app in function [OK]
- Thinking app is created globally
- Confusing with blueprint usage
- Assuming it auto-generates templates
Solution
Step 1: Check function definition and app creation
The factory function must create a Flask instance inside it using Flask(__name__)Step 2: Verify return of the app instance
The function should return the created app instance, not the class or a global variable.Final Answer:
def create_app():\n app = Flask(__name__)\n return app -> Option CQuick Check:
Factory returns new Flask instance [OK]
- Returning Flask class instead of instance
- Using global app outside function
- Not calling Flask with parentheses
print(app.config['DEBUG']) output?def create_app():
app = Flask(__name__)
app.config['DEBUG'] = True
return app
app = create_app()
print(app.config['DEBUG'])Solution
Step 1: Analyze config setting inside factory
The factory sets app.config['DEBUG'] = True before returning the app.Step 2: Check printed value after app creation
After calling create_app(), app.config['DEBUG'] is True, so printing it outputs True.Final Answer:
True -> Option AQuick Check:
Config set to True inside factory [OK]
- Assuming default DEBUG is False
- Expecting KeyError for missing key
- Confusing config with environment variables
def create_app():
app = Flask(__name__)
app.register_blueprint(main)
return app
app = create_app()Assume
main is a blueprint imported correctly.Solution
Step 1: Check blueprint registration timing
Blueprints are registered on the app instance inside the factory function, which is correct.Step 2: Verify app context and function structure
No app context push is needed for registration; the code is valid and follows the pattern.Final Answer:
No error, code is correct -> Option AQuick Check:
Blueprint registered inside factory is valid [OK]
- Thinking app context is needed for registration
- Trying to register blueprint before app exists
- Separating registration unnecessarily
Solution
Step 1: Understand extension initialization pattern
Extensions are usually created globally without app, then initialized with app inside the factory using init_app(app).Step 2: Why not create inside factory?
Creating inside factory loses global access; initializing outside factory after app creation breaks pattern.Final Answer:
Initialize the extension globally, then call init_app(app) inside the factory -> Option BQuick Check:
Global extension + init_app(app) inside factory [OK]
- Creating extension instance inside factory only
- Initializing extension outside factory after app creation
- Passing app to extension constructor inside factory
Ready to prove it?
Pass the test and this pattern moves unknown
