Episode goal: show configuration handled the Chenile way — modular, path-level runtime overrides, per-tenant, source-agnostic — and demo a live override without a redeploy.
Cold open
On camera: “A service is logic, policies — and configuration. Most teams treat that third one as an afterthought. Chenile doesn’t. Meet
cconfig.”Module owns its config
On screen: open
ctest.json. Voiceover: “Every module owns a JSON file named after it. A value can be a simple string or a deeply nested object. Config lives next to the module that owns it.”The headline feature
Lower third: “Override any value — down to the path — at runtime.” Voiceover: “You’re not stuck replacing whole values.”
Demo — path overrides
Live: override
key1; then override just key2.abc leaving the rest intact; then change key2.fields.field1.range[1] from 100 to 101; then add a whole new field2 snippet. “No editing the base file. No redeploy.”Per-tenant
Voiceover: “Overrides can apply to every request — or only when a custom attribute matches. In SaaS that’s the tenant ID. So one setting differs per tenant, resolved automatically, while the base config stays shared and clean.”
Demo — tenant switch
Send the same request with two different tenant IDs; show cconfig returning different effective values for the same key.
One client, many sources
On screen: the retrievers — Properties, JSON, Environment, Database (
cconfig-db) — behind CconfigClient, with a memory cache in front. “Start with JSON files; later move overrides into a database for a live admin UI — without changing the code that reads config.”Callback
“Same move as always: depend on the client interface, choose the source by configuration.”
Recap card
“cconfig = modular JSON config · path-level runtime overrides · per-tenant custom attribute · pluggable sources behind
CconfigClient.”Companion reading: Configuration management with cconfig