Learn Flask Design Patterns And Project Structure

Architecting Flask Applications

Flask is advertised as a simple, lightweight framework to get you started quickly with Python web development. While that’s true, I find there isn’t enough guidance on how to structure projects properly. Here is a list of some commonly used patterns to better help explain what options are available in different scenarios.

Single Module

A single file that you typically come across when looking for Flask examples, often an app.py. This is good enough for quick projects where only a few routes are needed and you have less than a few hundred lines of code.

app.py
config.py
requirements.txt
static/
templates/

Package

When you are working on projects that are more complex, for example, if you need to define models and forms. With this pattern, you can create separate components for your application.

config.py
requirements.txt
run.py
instance/
    config.py
app/
    __init__.py
    views.py
    models.py
    forms.py
    static/
    templates/

Blueprints

The concept of blueprints in Flask allows you to make applications modular and more maintainable by breaking up the application into smaller groups to better separate concerns.

config.py
requirements.txt
run.py
instance/
    config.py
app/
    blueprints/
        admin/
            templates/
                admin/
                    index.html
            __init__.py

Application Factories

To further improve the developer experience if you are already using blueprints in your application, an application factory pattern can assist with:

• Preventing circular imports (when two modules depend on each other)
• Easier testing in different environments (local, dev, staging, production)
• Easier application configuration (different keys/secrets for different environments, different databases, etc)

config.py         # contains most of the configuration variables your app needs
requirements.txt  # Python packages your application depends on
run.py            # application entry point invoked at start up  
instance/         # configuration directory not for version control
    config.py     # configuration variables for application secrets
app/              # application package
    __init__.py   # application factory method, this initializes the app
    routes.py     # where the routes are defined
    models.py     # database models
    forms.py      # login/register forms, etc
    static/       # public files like javascript, css, images
    templates/    # Jinja templates/ application pages

Application Factory with Blueprints

The best of both worlds. This is typically recommended for large applications but even medium-size applications can benefit from this pattern.

config.py           # contains most of the configuration variables your app needs
requirements.txt    # Python packages your application depends on
run.py              # application entry point invoked at start up  
instance/           # configuration directory not for version control
    config.py       # configuration variables for application secrets
app/                # application package
    __init__.py     # application factory method
    api/            # api blueprints package
        __init__.py # initializes blueprint
				errors.py   # custom api error classes
				users.py    # api user routes
				tokens.py   # api token routes
    models.py       # database models
    forms.py        # login/register forms, etc
    static/         # javascript, css, images
    templates/      # Jinja templates/ application pages

Thank you for reading, and don’t forget to connect

Find me on Twitter, LinkedIn, or my personal site and say hi. Best.