App Configs
In the previous chapter we built our first and simple app. And we had to
create an app.ini file to run it. So we can say that app configs
play a central role in spinning up your apps and developing WebFluid projects.
The core concept
App configs are the CLI's entry point into your project. They replace .env files and
tell the framework which app to run.
Primarily it is used to store secrets, potentially risky information (like database uris) and switches.
Switches are another core concept of WebFluid. The framework uses them to enroll features and extensions
on startup. Or in other words: They make the framework magic optioned.
Sections
App configs are parsed using Pythons configparser. Primarily, we are using sections to logically separate parts of your apps' configuration. A fully qualified example would look like this:
[general]
SECRET_KEY = supersecret
[extensions]
EXT_SCHEDULING = 0
EXT_SQLALCHEMY = 1
EXT_BABEL = 1
EXT_SECURITY = 0
EXT_EVENTS = 1
EXT_CACHE = 0
EXT_MAIL = 1
EXT_JWT = 0
[features]
WF_THEMES = 1
WF_TAILWIND = 1
WF_PROCESSING = 1
WF_ADDITIVES = 1
[data]
DATABASE_URI = sqlite:///test.db
REDIS_URI = redis://localhost:6379
[security]
SECURITY_SECRET = another-secret
[mail]
MAIL_USERNAME = noreply@example.org
MAIL_PASSWORD = supersecret
[additives]
my_additive = 1We used "general" for our logical defaults, but since it is just logical separation, you are not forced to stick with our defaults. This, of course, applies to all the sections shown above.
The [extensions] and [features] switches are the ones the framework
reads on startup to enroll its magic. Everything else is just plain configuration that ends up
in your apps' environment. The [additives] section toggles the Additives that are
installed in your project (more on that in the Additives chapters), and [security]
carries the SECURITY_SECRET that the security battery requires once you enable
EXT_SECURITY.
Secrets from files
Storing raw secrets inside a config file is fine for development, but in production you usually
mount them as files (think Docker or Kubernetes secrets). For every config key you can append a
_FILE suffix and point it at a file instead. The CLI reads the file and exposes its
content under the key without the suffix.
[general]
SECRET_KEY_FILE = /run/secrets/secret_key
[security]
SECURITY_SECRET_FILE = /run/secrets/security_secret
In this example your app sees SECRET_KEY and SECURITY_SECRET with the
contents of the referenced files. If the file does not exist, the raw value (the path) is kept as
a fallback.
File backed values are only resolved by wf run. The migration environment
(wf migrate) currently passes *_FILE keys through verbatim, so a
migration may not see the real secret behind them.
The dev section
One section name is special: [dev]. Its values are only applied when you run your app
in debug mode (the -d / --debug flag). This lets you keep development only
overrides next to your production configuration without leaking them into a normal run.
[general]
SECRET_KEY = supersecret
[dev]
DATABASE_URI = sqlite:///dev.dbContinue reading
From here you can continue straight with Config Classes.