Quickstart Python

In pochi minuti il tuo servizio Python 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: l’SDK è pura libreria standard, su Python 3.11 e successivi. Funziona allo stesso modo dentro un’app asyncio — la valutazione è una semplice lettura in memoria, quindi non c’è nulla da attendere con await.

1. Installa

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

pip install "git+https://github.com/FortressFlag/FortressFlag_SDK_python@v1.0.0"

Se ometti @v1.0.0, seguirai invece il branch development — comodo per provare un fix, non quello che vuoi in produzione.

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

import os

import fortressflag

try:
    client = fortressflag.create(
        fortressflag.Configuration(key=os.environ["FF_SERVER_KEY"])
    )
except fortressflag.MalformedKeyError:
    # L'unico punto in cui l'SDK solleva un'eccezione: una chiave malformata, prima che qualsiasi cosa venga servita.
    raise SystemExit(1)

client.start(timeout=15.0)  # ritorna al primo ruleset (o alla scadenza)

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

start non solleva mai eccezioni — se il primo fetch non riesce ad arrivare in tempo, il client continua a riprovare sul suo thread in background e nel frattempo i tuoi chiamanti ricevono i loro fallback. Il poller è un thread daemon: non impedisce mai al tuo interprete di terminare.

4. Valuta un flag

enabled = client.bool_value(
    "new-checkout",
    fortressflag.Context(
        key="user-42",  # la tua chiave di contesto stabile: un id utente, un id sessione — scegli tu
        tags={"cohort": "beta"},
    ),
    False,  # il fallback se il flag è sconosciuto o non è mai stato scaricato nulla
)

client.string_value e client.number_value 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_value, string_value e number_value rispondono sempre e non sollevano mai eccezioni — 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 cache_path 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