Application settings

@veap/settings provides typed key-value settings persisted through @veap/database and cached through the kernel cache contract.

Register providers#

import { Application } from "@veap/kernel";
import { DatabaseServiceProvider } from "@veap/database";
import { SettingsServiceProvider } from "@veap/settings";

export const app = Application.configure()
  .use(DatabaseServiceProvider)
  .use(SettingsServiceProvider)
  .create();

Check the installed provider constructor for the supported configuration shape. In production, use an explicit migration strategy instead of allowing every application instance to change the schema at startup.

Read and write values#

import { app } from "@veap/kernel";
import { SettingsService } from "@veap/settings";

const settings = await app(SettingsService);
const siteName = await settings.get<string>("site.name", "My site");
await settings.set("features.comments", true);
await settings.remove("obsolete.key");

The service exposes get<T>(key, defaultValue?), has(key), set(key, value), remove(key), clear(), and all(). Values are intended to be JSON-compatible. get() returns the default value when no persisted value exists; without a default, its result may be null.

Cache behavior#

Reads use a settings:<key> cache key. Writes update persistence and cache; removals delete the persisted setting and its cache entry. The service depends on the injected cache provider and settings repository. If you change repository behavior or cache backends, test invalidation across instances.

What belongs in settings?#

Good candidates include site title, feature flags, configurable presentation options, and integration toggles. Do not store passwords, API secrets, or private keys in ordinary application settings unless the application has an explicit secret-encryption and access-control design.