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_CHECK_FRONTEND = 0
WF_BUILD_FRONTEND = 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.
Two of the feature switches only matter for apps with a real frontend build:
WF_CHECK_FRONTEND type-checks your workspaces on startup and
WF_BUILD_FRONTEND builds them. Both are production-only — in debug mode the
Vite dev server takes over, and neither switch is read. We will come back to them in the
Frontend chapters.
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.
Both entry points into your project resolve these the same way now: wf run and the
migration environment behind wf migrate share one config parser, so a migration sees
the real secret behind a file backed key.
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.