Guide de démarrage Go

En quelques minutes, votre service Go é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 require du SDK est vide, et le reste.

1. Installez

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

go get github.com/FortressFlag/FortressFlag_SDK_go@v1.0.0

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

package main

import (
  "context"
  "os"
  "time"

  fortressflag "github.com/FortressFlag/FortressFlag_SDK_go"
)

func main() {
  client, err := fortressflag.New(fortressflag.Configuration{
    Key: os.Getenv("FF_SERVER_KEY"),
  })
  if err != nil {
    // Le seul endroit où le SDK peut renvoyer une erreur : une configuration
    // malformée, avant que quoi que ce soit ne serve.
    panic(err)
  }
  defer client.Close()

  startCtx, cancel := context.WithTimeout(context.Background(), 15*time.Second)
  client.Start(startCtx) // bloque jusqu’à l’arrivée du premier ruleset (ou la fin du contexte)
  cancel()

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

Start ne renvoie jamais d’erreur fatale — 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 valeurs par défaut entre-temps.

4. Évaluez un flag

enabled := client.Bool("new-checkout", fortressflag.Context{
  Key:  "user-42", // votre clé de contexte stable : un id d’utilisateur, un id de session — à vous de choisir
  Tags: map[string]string{"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

Bool, String et Number répondent toujours et ne paniquent jamais — 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

• Comment les flags arrivent à votre app — le plan serveur, expliqué
• Clés — créez, faites tourner et révoquez les clés ffs_
• Ciblage — les règles que votre service évalue désormais