Ga naar inhoud

Node.js-quickstart

Binnen een paar minuten evalueert je Node-service feature flags in-process — geen netwerkstap per controle, geen latentie in je verzoekpad, één poll die elk verzoek bedient dat je proces afhandelt.

Nul runtime-dependencies: het dependencies-blok van het package bestaat niet, en blijft dat.

De SDK leeft in een publieke repository op GitHub — installeer hem rechtstreeks van daar, vastgepind op de release:

Terminal window
npm install github:FortressFlag/FortressFlag_SDK_node#v1.0.0

Laat je #v1.0.0 weg, dan volg je in plaats daarvan de branch development — handig om een fix te proberen, niet wat je in productie wilt.

Het package is ESM-only. Op Node 22 en later kan CommonJS-code hem ook laden met een gewone require("@fortressflag/sdk-node").

Deze SDK gebruikt een serversleutel (ffs_…), en die is het tegenovergestelde van de clientsleutels die de mobiele en web-SDK’s meesturen: hij kan je volledige ruleset downloaden, targetingregels inbegrepen. Behandel hem precies als een databasewachtwoord — een omgevingsvariabele of een secret manager, nooit code, nooit een repository, nooit een log. De twee sleutelklassen, naast elkaar.

import { create } from "@fortressflag/sdk-node";
let client;
try {
client = create({ key: process.env.FF_SERVER_KEY });
} catch (error) {
// De ene plek waar de SDK gooit: een misvormde sleutel, voordat er iets serveert.
console.error(error);
process.exit(1);
}
await client.start(AbortSignal.timeout(15_000)); // resolvet bij de eerste ruleset (of de deadline)
// ... je service draait; flagcontroles zijn nu functieaanroepen in het geheugen.

start rejectt nooit — kan de eerste fetch niet op tijd landen, dan blijft de client het op de achtergrond proberen en krijgen je aanroepers intussen hun fallbacks. En de poller houdt je proces nooit in leven: is je code klaar, dan stopt Node zoals altijd.

const enabled = client.bool(
"new-checkout",
{
key: "user-42", // je stabiele contextsleutel: een gebruikers-id, een sessie-id — jouw keuze
tags: { cohort: "beta" },
},
false, // de fallback als de flag onbekend is of er nooit iets is opgehaald
);

client.string en client.number werken op dezelfde manier. De context-key is waar percentage-rollouts op bucketten — geef consequent dezelfde identifier mee en elke gebruiker krijgt een stabiel cohort. Het zijn jouw gegevens: de SDK valideert, bewaart of logt ze nooit.

Dat is het — je service evalueert flags lokaal. Een dashboardwijziging bereikt elk proces binnen ongeveer een minuut.

bool, string en number geven altijd antwoord en gooien nooit — een flagprobleem mag nooit je service neerhalen. Een herstart proces serveert je fallbacks van de aanroepplek tot zijn eerste fetch landt (of zet cachePath in de configuratie om de laatste ruleset naar een bestand naar keuze te bewaren, en herstarts hervatten er onmiddellijk uit). Zelfs een ingetrokken sleutel breekt niets: de SDK blijft evalueren met de laatst gedownloade ruleset tot je hem een nieuwe sleutel geeft.