Aller au contenu
FortressFlag Docs

Guide de démarrage Node.js

En quelques minutes, votre service Node évaluera des feature flags in-process — aucun saut réseau par vérification, aucune latence sur le chemin de vos requêtes, un seul polling servant chaque requête que votre processus traite.

Zéro dépendance à l’exécution : le bloc dependencies du package n’existe pas, et le reste.

1. Installez

Section intitulée « 1. Installez »

Le SDK vit dans un dépôt public sur GitHub — installez-le directement depuis là, épinglé sur la version publiée :

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

Sans #v1.0.0, vous suivez la branche development à la place — pratique pour essayer un correctif, pas ce que vous voulez en production.

Le package est ESM uniquement. Sur Node 22 et ultérieur, du code CommonJS peut aussi le charger avec un simple require("@fortressflag/sdk-node").

2. La clé serveur — un vrai secret

Section intitulée « 2. La clé serveur — un vrai secret »

Ce SDK utilise une clé serveur (ffs_…), et c’est l’opposé des clés client embarquées par les SDK mobiles et web : elle peut télécharger votre ruleset complet, règles de ciblage incluses. Traitez-la exactement comme un mot de passe de base de données — une variable d’environnement ou un gestionnaire de secrets, jamais du code, jamais un dépôt, jamais un journal. Les deux classes de clés, côte à côte.

3. Démarrez le client

Section intitulée « 3. Démarrez le client »
import { create } from "@fortressflag/sdk-node";


let client;
try {
  client = create({ key: process.env.FF_SERVER_KEY });
} catch (error) {
  // Le seul endroit où le SDK lève une exception : une clé malformée, avant que quoi que ce soit ne serve.
  console.error(error);
  process.exit(1);
}


await client.start(AbortSignal.timeout(15_000)); // se résout au premier ruleset (ou à l’échéance)


// ... votre service tourne ; les vérifications de flags sont désormais des appels de fonction en mémoire.

start n’est jamais rejeté — si la première récupération ne peut pas aboutir à temps, le client continue d’essayer en arrière-plan et vos appelants reçoivent leurs replis entre-temps. Et le poller ne maintient jamais votre processus en vie : quand votre code se termine, Node s’arrête comme d’habitude.

4. Évaluez un flag

Section intitulée « 4. Évaluez un flag »
const enabled = client.bool(
  "new-checkout",
  {
    key: "user-42", // votre clé de contexte stable : un id d’utilisateur, un id de session — à vous de choisir
    tags: { cohort: "beta" },
  },
  false, // le repli si le flag est inconnu ou si rien n’a jamais été récupéré
);

client.string et client.number fonctionnent de la même façon. La key du contexte est ce sur quoi les déploiements progressifs répartissent — passez le même identifiant de façon cohérente et chaque utilisateur obtient une cohorte stable. Ce sont vos données : le SDK ne les valide, ne les stocke ni ne les journalise jamais.

C’est tout — votre service évalue les flags localement. Un changement dans le tableau de bord atteint chaque processus en une minute environ.

L’évaluation n’échoue jamais

Section intitulée « L’évaluation n’échoue jamais »

bool, string et number répondent toujours et ne lèvent jamais d’exception — un problème de flags ne doit jamais faire tomber votre service. Un processus redémarré sert les replis de vos points d’appel jusqu’à ce que sa première récupération aboutisse (ou définissez cachePath dans la configuration pour persister le dernier ruleset dans un fichier de votre choix, et les redémarrages reprennent depuis celui-ci instantanément). Même une clé révoquée ne casse rien : le SDK continue d’évaluer avec le dernier ruleset qu’il a téléchargé jusqu’à ce que vous lui donniez une nouvelle clé.

Où aller ensuite

Section intitulée « Où aller ensuite »