Application Dispatching

The fundamental difference from the module approach is that in this case you are running the same ordifferent Flask applications that are entirely isolated from each other.They run different configurations and are dispatched on the WSGI level.

Each of the techniques and examples below results in an objectthat can be run with any WSGI server. For production, see .For development, Werkzeug provides a builtin server for development availableat werkzeug.serving.run_simple():

Note that is not intended foruse in production. Use a full-blown WSGI server.

from flask import Flask
from werkzeug.serving import run_simple
 
app = Flask(__name__)
app.debug = True
 
@app.route('/')
def hello_world():
    return 'Hello World!'
 
if __name__ == '__main__':
    run_simple('localhost', 5000, app,
               use_reloader=True, use_debugger=True, use_evalex=True)

If you have entirely separated applications and you want them to work nextto each other in the same Python interpreter process you can takeadvantage of the werkzeug.wsgi.DispatcherMiddleware. The ideahere is that each Flask application is a valid WSGI application and theyare combined by the dispatcher middleware into a larger one that isdispatched based on prefix.

For example you could have your main application run on / and yourbackend interface on :

Sometimes you might want to use multiple instances of the same applicationwith different configurations. Assuming the application is created insidea function and you can call that function to instantiate it, that isreally easy to implement. In order to develop your application to supportcreating new instances in functions have a look at the pattern.

The perfect level for abstraction in that regard is the WSGI layer. Youwrite your own WSGI application that looks at the request that comes anddelegates it to your Flask application. If that application does notexist yet, it is dynamically created and remembered:

from threading import Lock
 
class SubdomainDispatcher(object):
 
    def __init__(self, domain, create_app):
        self.create_app = create_app
        self.lock = Lock()
        self.instances = {}
 
    def get_application(self, host):
        host = host.split(':')[0]
        assert host.endswith(self.domain), 'Configuration error'
        subdomain = host[:-len(self.domain)].rstrip('.')
        with self.lock:
            app = self.instances.get(subdomain)
            if app is None:
                app = self.create_app(subdomain)
                self.instances[subdomain] = app
            return app
 
    def __call__(self, environ, start_response):
        app = self.get_application(environ['HTTP_HOST'])
        return app(environ, start_response)

This dispatcher can then be used like this:

Dispatching by a path on the URL is very similar. Instead of looking atthe Host header to figure out the subdomain one simply looks at therequest path up to the first slash:

from threading import Lock
from werkzeug.wsgi import pop_path_info, peek_path_info
 
class PathDispatcher(object):
    def __init__(self, default_app, create_app):
        self.default_app = default_app
        self.create_app = create_app
        self.lock = Lock()
        self.instances = {}
 
    def get_application(self, prefix):
        with self.lock:
            app = self.instances.get(prefix)
            if app is None:
                app = self.create_app(prefix)
                if app is not None:
                    self.instances[prefix] = app
            return app
 
    def __call__(self, environ, start_response):
        app = self.get_application(peek_path_info(environ))
        if app is not None:
            pop_path_info(environ)
        else:
            app = self.default_app
        return app(environ, start_response)