Feature-Flags ohne Deployment

Engineering

Manche Werte haben in deiner Codebasis nichts zu suchen.

Der Text des Banners auf der Startseite. Der Rabatt in Prozent bei der Sommeraktion. Das Flag, das einen halbfertigen Checkout vor allen außer deinem Team versteckt. Jede dieser Änderungen ist eine Zeile und kostet trotzdem einen Pull Request, ein Review, einen CI-Lauf und ein Deployment. Und wer die Änderung eigentlich will, kann sie meist nicht selbst machen.

Config ist ein Key-Value-Store, und genau darum geht es

Das Config-Modul von Kookee (im Dashboard Konfiguration) speichert jeden JSON-serialisierbaren Wert unter einem Key und liefert ihn über dasselbe SDK aus wie den Rest deiner Inhalte:

TypeScript
const flag = await kookee.config.getByKey('feature-new-checkout');

if (flag.value === true) {
  // neuer Checkout
}

Werte sind nicht auf Booleans beschränkt, und genau da wird es richtig nützlich. Eine ganze UI-Konfiguration passt unter einen Key:

TypeScript
const banner = await kookee.config.getByKey('homepage-banner');
// { text: 'Sommer-Sale!', enabled: true, color: '#ff6b00' }

Oder eine Geschäftsregel, die dein Finanzteam selbst verwalten will:

TypeScript
const discount = await kookee.config.getByKey('pricing-discount');
// { percentage: 20, minOrderValue: 50 }

Hol alles Nötige mit einem Aufruf

Keys einzeln bei jedem Seitenaufruf abzurufen ist der naheliegende Fehler. list() akzeptiert einen Key-Filter:

TypeScript
const configs = await kookee.config.list({
  keys: ['homepage-banner', 'feature-new-checkout', 'pricing-discount'],
});

Eine Anfrage, drei Werte. Hol sie einmal pro Render auf dem Server oder einmal beim App-Start auf dem Client und reich sie nach unten weiter. Jeder Config-Abruf ist ein API-Aufruf, der von deinem monatlichen Anfragekontingent abgeht. Im Free-Plan sind das 100.000 Anfragen im Monat. Caching ist hier also keine verfrühte Optimierung, sondern der normale Weg.

Die Versionshistorie ist das Sicherheitsnetz

Werte, die sich im laufenden Betrieb ändern lassen, sind nur dann angenehm, wenn Fehler billig sind. Jede Config-Änderung in Kookee erzeugt einen Snapshot, und jede Version der letzten 30 Tage lässt sich mit einem Klick wiederherstellen.

Damit ist es weniger riskant, einen Key jemandem ohne Entwicklerhintergrund zu überlassen. Der schlimmste Fall bei einem vertippten Rabatt ist kein Incident mit Hotfix-Deployment, sondern ein Rollback im Dashboard: Wer den Wert geändert hat, setzt ihn selbst zurück, zehn Sekunden nachdem er den Fehler bemerkt.

Beschreibungen sind aus demselben Grund wichtiger, als man denkt. enable-v2 sagt der Person, die den Key in sechs Monaten erbt, gar nichts. Schreib die Beschreibung, wenn du den Key anlegst.

Wo Config aufhört

Config ist bewusst einfach: ein Key, ein Wert und eine Historie. Prozentuale Rollouts, Targeting pro Nutzer oder A/B-Zuteilung gibt es nicht. Wenn du eine Funktion 5 % der Nutzer in Deutschland zeigen willst, brauchst du eine spezialisierte Experimentierplattform, und dann solltest du auch eine nutzen.

Config deckt den viel häufigeren Fall ab: einen globalen Wert, den dein Team ändern muss, ohne Code auszuliefern. Das trifft auf die meisten Flags fast immer zu. Außerdem liegt das Flag dann neben deinen Blogposts, Hilfeartikeln und deinem Changelog, hinter demselben API-Schlüssel, und dein Stack bekommt keinen vierten Anbieter.

Ein sinnvolles Muster: Behalte einen Standardwert im Code und lass Config ihn überschreiben:

TypeScript
let showNewCheckout = false;

try {
  const flag = await kookee.config.getByKey('feature-new-checkout');
  showNewCheckout = flag.value === true;
} catch {
  // Netzwerkaussetzer: sicheren Standardwert behalten
}

Jetzt lässt sich das Flag aus der Ferne steuern, und ist die API nicht erreichbar, bleibt es beim zuletzt bewährten Verhalten statt einer Exception auf der Checkout-Seite.