Simplify deployment

[rragundez]

Having now gone a bit deeper into the configuration/setting/deployment setup I believe there is the need to simplify and adopt single ways of doing things. At the moment the configuration/setting/deployment is a bit scattered and perhaps confusing for a new user, including the documentation, but I think the documentation issues are a consequence of how the code is structured.

For example I propose that:

• There should be a single Dockerfile and docker compose. With the option of a docker compose override of course and similar. At the moment there seems to be this concept of scripts that are quite messy and they seem to be a copy paste with different parts commented out.
• The definition of local, staging and production should be dynamic and set in a single source of truth via the environment variable. Every configuration in the application code or deployment code has to prioritize this environment variable as the single source of truth and only define it somewhere else based on strict exceptions. At the moment the definition of the environment level is in many places, hardcoded in docs, file/dir names, in instructions, etc.
• The app should work out of the box with docker compose and not with a non-containarized local deployment. Making docker a first-class citizen. Trying to support non-containarized local deployments as first-class citizens is just asking for trouble IMO.
• The default version of the app should use the local environment and be tailored to work out of the box (without an .env file) with docker compose. This will allow users to immediately be able to deploy and have it working without any type of setup or having to read documentation (which is what detracts adoption of these kinda projects IMO, the user wants to use it/feel it before investing time into knowing it).
• The deployment should support out of the box both via the Dockerfile as a single service or via docker compose. This would enable the user to use it as the user wants, for example, via a more complete deployment via K8S (or similar) or a simple but yet powerful deployment using container based cloud services (Cloud Run, App Runner, etc.)
• There should be a single tool gunicorn or uvicorn to run the application for all environments, preferably with de default of 2 workers (via environment variables). There are many issues that come once the system scales having multiple copies, having a consistent deplyoment with at least 2 workers can minimize the overlooking of such bugs. Even better would be to mimic the deployment of different containers but that can come after.

I think making these changes will contribute on the greater adoption of the boiler plate. I am sure more things will come up once these changes are made but the main idea is to make it simple to the user, without having to read complicated documentation, specially because the type of user of this code is already savvy so there is no need to explain everything.

I already submitted PRs that slowly start addressing these points, but just want communicate my intention as a whole. PRs #222 #223 #225