Merge pull request #4591 from moondial-pal/docs-omit-becomingbigrst

Docs omit becomingbigrst

docs/becomingbig.rst

@@ -1,100 +0,0 @@
-Becoming Big
-============
-
-Here are your options when growing your codebase or scaling your application.
-
-Read the Source.
-----------------
-
-Flask started in part to demonstrate how to build your own framework on top of
-existing well-used tools Werkzeug (WSGI) and Jinja (templating), and as it
-developed, it became useful to a wide audience.  As you grow your codebase,
-don't just use Flask -- understand it.  Read the source.  Flask's code is
-written to be read; its documentation is published so you can use its internal
-APIs.  Flask sticks to documented APIs in upstream libraries, and documents its
-internal utilities so that you can find the hook points needed for your
-project.
-
-Hook. Extend.
--------------
-
-The :doc:`/api` docs are full of available overrides, hook points, and
-:doc:`/signals`. You can provide custom classes for things like the
-request and response objects. Dig deeper on the APIs you use, and look
-for the customizations which are available out of the box in a Flask
-release. Look for ways in which your project can be refactored into a
-collection of utilities and Flask extensions. Explore the many
-:doc:`/extensions` in the community, and look for patterns to build your
-own extensions if you do not find the tools you need.
-
-Subclass.
----------
-
-The :class:`~flask.Flask` class has many methods designed for subclassing. You
-can quickly add or customize behavior by subclassing :class:`~flask.Flask` (see
-the linked method docs) and using that subclass wherever you instantiate an
-application class. This works well with :doc:`/patterns/appfactories`.
-See :doc:`/patterns/subclassing` for an example.
-
-Wrap with middleware.
----------------------
-
-The :doc:`/patterns/appdispatch` pattern shows in detail how to apply middleware. You
-can introduce WSGI middleware to wrap your Flask instances and introduce fixes
-and changes at the layer between your Flask application and your HTTP
-server. Werkzeug includes several `middlewares
-<https://werkzeug.palletsprojects.com/middleware/>`_.
-
-Fork.
------
-
-If none of the above options work, fork Flask.  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.
-Furthermore integrating upstream changes can be a complex process,
-depending on the number of changes.  Because of that, forking should be
-the very last resort.
-
-Scale 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, process or greenlet.  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.
-
-Discuss with the community.
----------------------------
-
-The Flask developers keep the framework accessible to users with codebases big
-and small. If you find an obstacle in your way, caused by Flask, don't hesitate
-to contact the developers on the mailing list or Discord server.  The best way for
-the Flask and Flask extension developers to improve the tools for larger
-applications is getting feedback from users.

docs/design.rst

@@ -167,9 +167,6 @@ large applications harder to maintain.  However Flask is just not designed
 for large applications or asynchronous servers.  Flask wants to make it
 quick and easy to write a traditional web application.
 
-Also see the :doc:`/becomingbig` section of the documentation for some
-inspiration for larger applications based on Flask.
-
 
 Async/await and ASGI support
 ----------------------------

docs/foreword.rst

@@ -47,7 +47,7 @@ SQLAlchemy or another database tool, introduce non-relational data persistence
 as appropriate, and take advantage of framework-agnostic tools built for WSGI,
 the Python web interface.
 
-Flask includes many hooks to customize its behavior. Should you need more
+Flask includes many hooks to customize its behavior. Should you need
-customization, the Flask class is built for subclassing. If you are interested
+more customization, the Flask class is built for subclassing. If you are
-in that, check out the :doc:`becomingbig` chapter.  If you are curious about
+curious about the Flask design principles, head over to the section
-the Flask design principles, head over to the section about :doc:`design`.
+about :doc:`design`.

docs/index.rst

@@ -58,7 +58,6 @@ instructions for web development with Flask.
    shell
    patterns/index
    deploying/index
-   becomingbig
    async-await
 
 

docs/patterns/packages.rst

@@ -173,10 +173,6 @@ You should then end up with something like that::
    ensuring the module is imported and we are doing that at the bottom of
    the file.
 
-   There are still some problems with that approach but if you want to use
-   decorators there is no way around that.  Check out the
-   :doc:`/becomingbig` section for some inspiration how to deal with that.
-
 
 Working with Blueprints
 -----------------------