Clarify add_static warning in documentation.

[stalkerg]

Describe the bug

Currently, in the documentation, we have the next warning for add_static (static handler):

Use add_static() for development only. In production, static content should be processed by web servers like nginx or apache.

The current explanation is not enough and makes it confusing. If the reason for this warning is only in performance, I suppose we can find many use cases in production where it can be used. If the reason is stability or even security it's a different situation.

Will be good to change this text in the documentation and clarify the reason for this warning.

Thanks!

To Reproduce

Read docs

Expected behavior

Clear explanation, in which case we can use static handler.

Logs/tracebacks

Not needed

Python Version

$ python --version

aiohttp Version

$ python -m pip show aiohttp

multidict Version

$ python -m pip show multidict

yarl Version

$ python -m pip show yarl

OS

Any

Related component

Server

Additional context

No response

Code of Conduct

• [X] I agree to follow the aio-libs Code of Conduct

[Dreamsorcerer]

In general web practice (under literally all frameworks/languages) it's considered good practice to serve static content from your web server (e.g. nginx) or a CDN, rather than invoking the web application which is a lot slower to handle such a simple request. Most users will already know this, so that's probably why it's not had much thought to expanding the explanation.

If you want to add some information to clarify usage, you could mention that there is probably no real harm in leaving the route in for production apps, as long as the web server is handling the static requests then the static handler would simply never be invoked (though not including the route would make it obvious if your web server is misconfigured).

If the reason for this warning is only in performance, I suppose we can find many use cases in production where it can be used.

Like what? It basically emulates the behaviour of serving files from a web server. I can't think of any case you'd want to do this in a production environment.

[stalkerg]

Like what? It basically emulates the behaviour of serving files from a web server. I can't think of any case you'd want to do this in a production environment.

Making separate deploy pipelines for static files in massive Kubernetes cluster(s) can include huge management and resource costs (separate static pod with nginx or CDN). Also, sometimes you do not fully control such clusters, like in the Heroku case. Also, because your data live outside of the container, you can have issues with synchronization, and in many simple pipelines you will.