Python-quickstart

Binnen een paar minuten evalueert je Python-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 dependencies: de SDK is pure standard library, op Python 3.11 en later. Hij werkt net zo goed binnen een asyncio-app — evaluatie is een gewone leesactie in het geheugen, dus er valt niets te awaiten.

1. Installeren

De SDK is pre-release en zijn repository is nog niet publiek. Heeft je team toegang gekregen, installeer hem dan rechtstreeks uit de repository:

pip install git+https://github.com/FortressFlag/FortressFlag_SDK_python

2. De serversleutel — een echt geheim

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.

3. Start de client

import os

import fortressflag

try:
    client = fortressflag.create(
        fortressflag.Configuration(key=os.environ["FF_SERVER_KEY"])
    )
except fortressflag.MalformedKeyError:
    # De ene plek waar de SDK raiset: een misvormde sleutel, voordat er iets serveert.
    raise SystemExit(1)

client.start(timeout=15.0)  # keert terug bij de eerste ruleset (of de deadline)

# ... je service draait; flagcontroles zijn nu functieaanroepen in het geheugen.

start raiset nooit — kan de eerste fetch niet op tijd landen, dan blijft de client het op zijn achtergrondthread proberen en krijgen je aanroepers intussen hun fallbacks. De poller is een daemon-thread: hij houdt je interpreter nooit tegen bij het afsluiten.

4. Evalueer een flag

enabled = client.bool_value(
    "new-checkout",
    fortressflag.Context(
        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_value en client.number_value 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.

Evaluatie faalt nooit

bool_value, string_value en number_value geven altijd antwoord en raisen nooit — een flagprobleem mag nooit je service neerhalen. Een herstart proces serveert je fallbacks van de aanroepplek tot zijn eerste fetch landt (of zet cache_path 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.

Waar nu heen?

• Hoe flags je app bereiken — het server plane, uitgelegd
• Sleutels — munt, roteer en trek ffs_-sleutels in
• Targeting — de regels die je service nu evalueert