CODEWITHSUNDEEP
flask
LBarret
LBarret

Reputation: 1123

In what situation, is there a need for more than one application in flask ? (not blueprint)

A lot of complexity in the flask code base is due to the fact that more than one app can be created. While I grasp the architecture to allow this, I don't quite get, is when does it happen ? Or Why one does need it ?

To be clear, I am not talking about blueprints. I am talking about something like : 

from flask import Flask, Blueprint

bp = Blueprint('common', __name__)

@bp.route('/')
def index():
    return 'Hello World!'

def make_app(filename):
    app = Flask(__name__)
    app.config.from_pyfile(filename)
    app.register_blueprint(bp)
    return app

app1 = make_app('config1.py')
app2 = make_app('config2.py')

Upvotes: 6

Views: 869

Answers (2)

tohster
tohster

Reputation: 7103

Nice question! I'll add a (hopefully) complementary approach to Miguel's.

The separation between apps, blueprints and modules in flask is quite powerful, although as you point out, it steepens the learning curve.

Blueprints provide a nice way to aggregate modules and features into a single group that can then be managed as a whole with its own routes, methods, etc. A blueprint can be more useful than a python "super-module" because it has predefined facilities in flask that make managing it easier (registering routes, etc). Blueprints are orthogonal to modules, and this is helpful because you can share modules between multiple blueprints even if they are configured differently.

Apps are orthogonal to both blueprints and modules. Whereas blueprints and modules are concerned with groups and hierarchies of features, apps are more concerned with the handling of sessions, processes, and overall data and communications scope. By decoupling (sessions/processes/data scope) from blueprints and modules, you get to separate how the application runs from what features/functions/blueprints it runs.

So why does this matter for apps? Here are some situations where the decoupling comes in handy:

  • Different feature scope - Your normal_app is a multiplayer game, and allows users to log in and play the game. You also have a set of game administrators who are able to log in and play the game but with superpowers (view additional information, kill unruly players, etc). You implement this by creating a admin_app that contains all the blueprints for the normal_app, but also an additional admin_superpowers blueprint.

  • Different session/process scope - You decide that you don't want to risk normal players hacking their system to be able to gain admin superpowers, so you now configure admin_app to run on a different server instance and with additional authentication protocols, to make sure access is separated from the normal_app.

  • Different communications scope - You decide that even if the normal game servers go down, you want the admin_app to keep running. So you reconfigure it to a different, more reliable application server, and to run on multiple ports for redundancy.

  • Different data scope - Your developers need to be able to test out new features, but obviously not using the live game. So you create a developer_app which contains all the blueprints for the normal_app but is configured to use a variety of dummy databases, and to spit out a variety of runtime diagnostics. Unlike the normal app, it is scaled down so also run on a developer's laptop.

...and so on. Hope that helps.

Upvotes: 5

Miguel Grinberg
Miguel Grinberg

Reputation: 67507

Very good question! I think you are looking at it in the wrong way. The idea is not to have multiple identical applications running side by side, I agree that this isn't very useful (except when testing, as I show in my last example below).

Consider that you can have multiple different applications running in the same process. For example, a web application and an API. Of course you can host them both as a single application, but if you want them to listen on different ports for security purposes, then the only way is to have two separate applications. You can certainly create the applications separately, but it may be more convenient to have them in the same process, at least during development.

Breaking up a big application into sub-applications can also be perceived as more secure, when you have some of the parts handling sensitive information that you don't want other parts to have access to. The separation between two applications is bigger than between two blueprints, so if you are concerned about security, attacks, etc. it may be a good idea to sandbox each sub-application into its own sub-package and have it listening on a separate port.

And I have one more. When writing unit tests, it is very useful to create an application specifically for each test, as this allows different configurations to be used according to what functionality each test needs to exercise. Consider that unit tests may be run in parallel for performance reasons, so here one more time you can benefit from having multiple apps that are active at the same time. It would not be good if Flask prevented you from running tests in parallel.

Upvotes: 4

Related Questions