Flask began as a demonstration of how to create your own framework using well-known tools like Werkzeug (WSGI) and Jinja (templating), but as it grew in popularity, it became helpful to a broader audience. Don't just utilize Flask as you expand your codebase; learn it. Check out the source. Flask's code is written to be read, and its documentation is available for users with its internal APIs. Flask follows upstream libraries' defined APIs and describes its internal utilities so you can locate the hook points you need for your project.

Hook and Extend: The API documentation is full of overrides, hook points, and Signals. Custom classes can be provided for request and response objects, for example. Look at the APIs you're using and see what customizations are available right out of the box in a Flask release. Look for ways to rework your project into a collection of Flask extensions and utilities. If you can't discover what you're looking for among the MANY Extensions in the community, seek for patterns to develop your own.

Subclass: Many methods of the Flask class are intended for subclassing. Subclassing Flask (see the linked method instructions) and using that subclass anywhere you instantiate an application class allows you to rapidly add or alter behavior. This is a great way to use Application Factories. For an example, see Flask Subclassing.

Wrap with middleware: The Application Dispatching pattern explains how to use middleware in detail. To encapsulate your Flask instances and introduce repairs and updates at the layer between your Flask application and your HTTP server, you can use WSGI middleware. Werkzeug comes with a number of middlewares.

FORK: Fork Flask if none of the preceding OPTIONS work. Werkzeug and Jinja2 contain the majority of Flask's code. The majority of the work is done by these libraries. Flask is simply the glue that holds them together. Every project has a moment where the underlying framework becomes a hindrance (due to assumptions the original developers had). This is understandable because if it weren't, the framework would be an extremely complex system from the start, resulting in a steep learning curve and a lot of user irritation.

For many online applications, code complexity is less of a concern than scaling for the expected number of users or data entries. Flask's scalability capabilities are restricted solely by your application code, the data store you choose to utilize, and the Python implementation and web server you're using.

Scaling well means, for example, that doubling the number of SERVERS yields roughly double the performance. Scaling poorly means that adding a new server will not improve performance or will not even support a second server. In Flask, the context local PROXIES are the only limiting element in terms of scaling. They are dependent on context, which is defined in Flask as a thread, process, or greenlet. Flask will no longer be able to support global proxies if your server uses a concurrency model that isn't based on threads or greenlets. However, the majority of servers achieve concurrency by using threads, greenlets, or different processes, all of which are fully supported by the Werkzeug framework.