Web-Quickstart

In ein paar Minuten liest deine Website ein echtes Feature Flag — mit einem dauerhaften Cache, einer fail-safen Antwort für jede Situation und nichts, was du im Browser verwalten musst.

Null Laufzeitabhängigkeiten; das ganze SDK bleibt unter einer Obergrenze von 10 kB gzip.

1. Installieren

Das SDK liegt in einem öffentlichen Repository auf GitHub — installiere es direkt von dort, auf das Release gepinnt:

npm install github:FortressFlag/FortressFlag_SDK_web#v1.0.0

Das Package baut sich bei der Installation selbst, und der Import unten ist sein Einstiegspunkt.

2. Starte das SDK

Einmal, früh im Bootstrap deiner Seite oder App:

import { Environment, FortressFlag } from "@fortressflag/sdk-web";

FortressFlag.start({
  sdkKey: "ffc_prod_…", // aus dem Bildschirm SDK-Schlüssel deines Projekts
  environment: Environment.PRODUCTION,
});

start kehrt sofort zurück; gecachte Werte aus früheren Besuchen sind sofort verfügbar, und frische Werte kommen im Hintergrund an. Der Schlüssel ist ein Client-Schlüssel — er ist by design in deinem Seitenquelltext sichtbar.

3. Lies ein Flag

if (FortressFlag.isEnabled("new-checkout", false)) {
  // den neuen Checkout rendern
}

stringValue und numberValue lesen multivariate Flags genauso, und FortressFlag.onChange sagt dir, wenn sich Werte bewegen, damit du neu rendern kannst.

Das war’s — dein Flag ist live. Schalte es im Dashboard um und öffne die Seite erneut (oder warte eine Abfrage ab), um zuzusehen, wie es folgt.

Hier wirft nie etwas

Kein Aufruf in dieser API wirft, und kein Promise daraus wird rejected. Jede Lesung löst sich über die Kaskade auf: der frischeste abgerufene Wert, dann der letzte Wert, den dieser Browser festgehalten hat, dann dein Standard, dann false. Ein FortressFlag-Ausfall, ein totes Netzwerk, ein Werbeblocker, ein widerrufener Schlüssel — alle lösen sich zu einem Flag-Wert auf, keiner erreicht deinen Code als Fehler.

(Der Werbeblocker-Fall ist real: Manche Privacy-Erweiterungen blockieren Flag-Requests. Gecachte Werte liefern weiter, und ein Browser, der nie abgerufen hat, liefert deine Standards — „Flags aktualisieren sich mit uBlock nicht“ ist die Kaskade bei der Arbeit, kein Bug.)

Was im Browser liegt, ehrlich

• Die Geräteidentität liegt in localStorage, gebunden an deinen Origin. Sie wird zufällig erzeugt und ist pseudonym — und lesbar für das eigene JavaScript deiner Seite, dieselbe Klasse von Wert wie der SDK-Schlüssel daneben.
• Private Fenster erzeugen Wegwerf-Identitäten. Jede private Sitzung zählt als Gerät, solange sie dauert; ein Nutzer, der Website-Daten löscht, ist ebenfalls ein neues Gerät. Und eine Person auf deiner Website, deiner iOS-App und deiner Android-App ist bis zu drei Geräte — es gibt keine plattformübergreifende Verknüpfung, mit Absicht.
• Deine Test-Suiten sind gratis. Browser, die von Playwright, Selenium, Puppeteer oder Cypress gesteuert werden, geben sich zu erkennen, und das SDK erzeugt dort eine sim_-Identität: Flags werden ausgeliefert, nie abgerechnet.
• Versions-Tags gibt es im Web nicht. Das SDK sendet platform und sdkVersion automatisch, aber es gibt keine verlässliche appVersion oder osVersion für eine Seite — eine Targeting-Regel darauf trifft auf einen Browser einfach nie zu.

Wie geht es weiter?

• Wie Flags deine App erreichen — Polling und der Cache
• Geräteidentität und Abrechnung — die Identität in diesem Speicherschlüssel
• Targeting — Regeln, Segmente und Rollouts