Quickstart Go

In pochi minuti il tuo servizio Go valuterà i feature flag in-process — nessun salto di rete per controllo, nessuna latenza nel percorso delle tue richieste, un solo poll che serve ogni richiesta gestita dal tuo processo.

Zero dipendenze a runtime: il blocco require dell’SDK è vuoto, e resta così.

1. Installa

L’SDK vive in un repository pubblico su GitHub — installalo direttamente da lì, fissato alla release:

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

2. La chiave server — un segreto vero e proprio

Questo SDK usa una chiave server (ffs_…), ed è l’opposto delle chiavi client che gli SDK mobile e web portano con sé: può scaricare il tuo ruleset completo, regole di targeting incluse. Trattala esattamente come la password di un database — una variabile d’ambiente o un secret manager, mai il codice, mai un repository, mai un log. Le due classi di chiavi, fianco a fianco.

3. Avvia il 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 {
    // L'unico punto in cui l'SDK può dare errore: una configurazione malformata,
    // prima che qualsiasi cosa venga servita.
    panic(err)
  }
  defer client.Close()

  startCtx, cancel := context.WithTimeout(context.Background(), 15*time.Second)
  client.Start(startCtx) // blocca finché arriva il primo ruleset (o il context termina)
  cancel()

  // ... il tuo servizio gira; i controlli dei flag ora sono chiamate di funzione in memoria.
}

Start non restituisce mai un errore fatale — se il primo fetch non riesce ad arrivare in tempo, il client continua a riprovare in background e nel frattempo i tuoi chiamanti ricevono i loro valori predefiniti.

4. Valuta un flag

enabled := client.Bool("new-checkout", fortressflag.Context{
  Key:  "user-42", // la tua chiave di contesto stabile: un id utente, un id sessione — scegli tu
  Tags: map[string]string{"cohort": "beta"},
}, false) // il fallback se il flag è sconosciuto o non è mai stato scaricato nulla

client.String e client.Number funzionano allo stesso modo. La Key del contesto è ciò su cui i rollout percentuali fanno il bucketing — passa lo stesso identificatore in modo coerente e ogni utente riceve una coorte stabile. Sono dati tuoi: l’SDK non li valida, memorizza o registra mai.

Fatto — il tuo servizio sta valutando i flag in locale. Una modifica nella dashboard raggiunge ogni processo entro circa un minuto.

La valutazione non fallisce mai

Bool, String e Number rispondono sempre e non vanno mai in panic — un problema con i flag non deve mai buttare giù il tuo servizio. Un processo riavviato serve i fallback dei tuoi punti di chiamata finché non arriva il primo fetch (oppure imposta CachePath nella configurazione per persistere l’ultimo ruleset in un file a tua scelta, e i riavvii riprendono da lì all’istante). Nemmeno una chiave revocata rompe qualcosa: l’SDK continua a valutare con l’ultimo ruleset scaricato finché non gli consegni una nuova chiave.

Prossimi passi

• Come i flag raggiungono la tua app — il piano server, spiegato
• Chiavi — genera, ruota e revoca le chiavi ffs_
• Targeting — le regole che il tuo servizio sta ora valutando