Flask Design Patterns And Project Structure

Flask Design Patterns And Project Structure

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.

Single module structure:

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.

Package structure:

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.

Blueprints structure:

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:

Factory structure:

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.

Factory with Blueprints structure:

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 erro 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