mirror of https://github.com/mitsuhiko/flask.git
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
76 lines
3.5 KiB
76 lines
3.5 KiB
.. _becomingbig: |
|
|
|
Becoming Big |
|
============ |
|
|
|
Your application is becoming more and more complex? If you suddenly |
|
realize that Flask does things in a way that does not work out for your |
|
application there are ways to deal with that. |
|
|
|
Flask is powered by Werkzeug and Jinja2, two libraries that are in use at |
|
a number of large websites out there and all Flask does is bring those |
|
two together. Being a microframework Flask does not do much more than |
|
combinding existing libraries - there is not a lot of code involved. |
|
What that means for large applications is that it's very easy to take the |
|
code from Flask and put it into a new module within the applications and |
|
expand on that. |
|
|
|
Flask is designed to be extended and modified in a couple of different |
|
ways: |
|
|
|
- Subclassing. The majority of functionality can be changed by creating |
|
a new subclass of the :class:`~flask.Flask` class and overriding |
|
some methods. |
|
|
|
- Flask extensions. For a lot of reusable functionality you can create |
|
extensions. |
|
|
|
- Forking. If nothing else works out you can just take the Flask |
|
codebase at a given point and copy/paste it into your application |
|
and change it. Flask is designed with that in mind and makes this |
|
incredible easy. You just have to take the package and copy it |
|
into your application's code and rename it (for example to |
|
`framework`). Then you can start modifying the code in there. |
|
|
|
Why consider Forking? |
|
--------------------- |
|
|
|
The majority of code of Flask is within Werkzeug and Jinja2. These |
|
libraries do the majority of the work. Flask is just the paste that glues |
|
those together. For every project there is the point where the underlying |
|
framework gets in the way (due to assumptions the original developers |
|
had). This is natural because if this would not be the case, the |
|
framework would be a very complex system to begin with which causes a |
|
steep learning curve and a lot of user frustration. |
|
|
|
This is not unique to Flask. Many people use patched and modified |
|
versions of their framework to counter shortcomings. This idea is also |
|
reflected in the license of Flask. You don't have to contribute any |
|
changes back if you decide to modify the framework. |
|
|
|
The downside of forking is of course that Flask extensions will most |
|
likely break because the new framework has a different import name and |
|
because of that forking should be the last resort. |
|
|
|
Scaling like a Pro |
|
------------------ |
|
|
|
For many web applications the complexity of the code is less an issue than |
|
the scaling for the number of users or data entries expected. Flask by |
|
itself is only limited in terms of scaling by your application code, the |
|
data store you want to use and the Python implementation and webserver you |
|
are running on. |
|
|
|
Scaling well means for example that if you double the amount of servers |
|
you get about twice the performance. Scaling bad means that if you add a |
|
new server the application won't perform any better or would not even |
|
support a second server. |
|
|
|
There is only one limiting factor regarding scaling in Flask which are |
|
the context local proxies. They depend on context which in Flask is |
|
defined as being either a thread or a greenlet. Separate processes are |
|
fine as well. If your server uses some kind of concurrency that is not |
|
based on threads or greenlets, Flask will no longer be able to support |
|
these global proxies. However the majority of servers are using either |
|
threads, greenlets or separate processes to achieve concurrency which are |
|
all methods well supported by the underlying Werkzeug library.
|
|
|