Node.js-Quickstart

In ein paar Minuten wertet dein Node-Service Feature Flags in-process aus — kein Netzwerk-Hop pro Prüfung, keine Latenz in deinem Request-Pfad, eine Abfrage versorgt jeden Request, den dein Prozess bedient.

Null Laufzeitabhängigkeiten: Der dependencies-Block des Packages existiert nicht und bleibt es.

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_node#v1.0.0

Lässt du #v1.0.0 weg, folgst du stattdessen dem Branch development — praktisch, um einen Fix auszuprobieren, aber nicht das, was du in Produktion willst.

Das Package ist ESM-only. Auf Node 22 und neuer kann CommonJS-Code es auch mit einem schlichten require("@fortressflag/sdk-node") laden.

2. Der Server-Schlüssel — ein echtes Geheimnis

Dieses SDK benutzt einen Server-Schlüssel (ffs_…), und der ist das Gegenteil der Client-Schlüssel, die die Mobil- und Web-SDKs ausliefern: Er kann dein vollständiges Ruleset herunterladen, Targeting-Regeln inklusive. Behandle ihn genau wie ein Datenbankpasswort — eine Umgebungsvariable oder ein Secret-Manager, nie Code, nie ein Repository, nie ein Log. Die zwei Schlüsselklassen, nebeneinander.

3. Starte den Client

import { create } from "@fortressflag/sdk-node";

let client;
try {
  client = create({ key: process.env.FF_SERVER_KEY });
} catch (error) {
  // Die eine Stelle, an der das SDK wirft: ein fehlerhafter Schlüssel, bevor irgendetwas ausliefert.
  console.error(error);
  process.exit(1);
}

await client.start(AbortSignal.timeout(15_000)); // resolved beim ersten Ruleset (oder der Frist)

// ... dein Service läuft; Flag-Prüfungen sind jetzt In-Memory-Funktionsaufrufe.

start wird nie rejected — wenn der erste Abruf nicht rechtzeitig landet, versucht der Client es im Hintergrund weiter, und deine Aufrufer bekommen inzwischen ihre Fallbacks. Und der Poller hält deinen Prozess nie am Leben: Wenn dein Code fertig ist, beendet sich Node wie gewohnt.

4. Werte ein Flag aus

const enabled = client.bool(
  "new-checkout",
  {
    key: "user-42", // dein stabiler Kontext-Key: eine User-ID, eine Session-ID — deine Wahl
    tags: { cohort: "beta" },
  },
  false, // der Fallback, wenn das Flag unbekannt ist oder nie etwas abgerufen wurde
);

client.string und client.number funktionieren genauso. Der Kontext-key ist das, worauf Prozent-Rollouts bucketen — übergib denselben Bezeichner konsistent, und jeder Nutzer bekommt eine stabile Kohorte. Es sind deine Daten: Das SDK validiert, speichert oder loggt sie nie.

Das war’s — dein Service wertet Flags lokal aus. Eine Dashboard-Änderung erreicht jeden Prozess innerhalb von etwa einer Minute.

Die Auswertung schlägt nie fehl

bool, string und number antworten immer und werfen nie — ein Flag-Problem darf deinen Service niemals lahmlegen. Ein neu gestarteter Prozess liefert deine Fallbacks von der Aufrufstelle, bis sein erster Abruf landet (oder setz cachePath in der Konfiguration, um das letzte Ruleset in einer Datei deiner Wahl zu persistieren, und Neustarts setzen sofort daraus fort). Selbst ein widerrufener Schlüssel macht nichts kaputt: Das SDK wertet mit dem zuletzt heruntergeladenen Ruleset weiter aus, bis du ihm einen neuen Schlüssel gibst.

Wie geht es weiter?

• Wie Flags deine App erreichen — die Server-Plane, erklärt
• Schlüssel — ffs_-Schlüssel erstellen, rotieren und widerrufen
• Targeting — die Regeln, die dein Service jetzt auswertet