Come i flag raggiungono la tua app

La tua app non chiama FortressFlag ogni volta che controlla un flag. Le letture dei flag sono locali — istantanee, sicure offline, senza rete nel percorso. Ciò che viaggia sulla rete è un poll periodico, e cosa recupera quel poll dipende da quale dei due piani stai usando.

Il piano client: le tue app ricevono risposte, non regole

Gli SDK iOS, Android e web usano il piano client. Il dispositivo invia la sua identità e i suoi tag; FortressFlag valuta le tue regole di targeting lato server e restituisce solo i valori di quel dispositivo — una piccola mappa come {"new-checkout": true, "dark-mode": false}.

Il dispositivo non riceve mai le tue regole. È voluto, per due motivi: la tua logica di targeting («coorte beta», «dispositivi interni») è affar tuo e non dovrebbe viaggiare dentro qualcosa che chiunque può estrarre dal binario di un’app — e il payload resta minuscolo.

Il piano client si autentica con una chiave client (ffc_…), che viaggia dentro la tua app ed è pubblica per progettazione — ne parliamo in Chiavi.

Il piano server: il tuo backend riceve il ruleset

L’SDK Go usa il piano server. Il tuo server scarica il ruleset completo di un progetto

• ambiente — tipi, valori predefiniti, regole, con i segmenti già appiattiti dentro — e valuta i flag nel proprio processo. Un controllo di flag è una chiamata di funzione su dati già in memoria: nessun salto di rete per controllo, nessuna latenza per richiesta, e un solo poll serve l’intero processo indipendentemente da quante richieste gestisce.

Poiché il ruleset include le tue regole di targeting, questo piano sta dietro una chiave server (ffs_…) — un segreto vero e proprio, gestito come la password di un database. E dato che le tue regole raggiungono ogni server che detiene quella chiave, il corollario sta a te applicarlo: non mettere segreti o dati personali dei tuoi utenti nelle condizioni delle regole.

Su questo piano non esiste un’identità del dispositivo. Il tuo codice passa una chiave di contesto per ogni valutazione — un ID utente, un ID sessione, qualunque cosa su cui fai il bucketing — e l’aritmetica del rollout la usa esattamente come il piano client usa l’ID del dispositivo, così lo stesso input finisce nella stessa coorte qualunque piano lo valuti.

Il polling, e perché è economico

Entrambi i piani fanno poll a intervalli, ed entrambi usano richieste condizionali: ogni risposta porta un validatore (un ETag), e quando nulla è cambiato dall’ultimo poll la risposta è un minuscolo «niente di nuovo» — nessun corpo, nessuna rivalutazione. Lo stato stazionario di una flotta che non sta cambiando flag è un flusso di controlli quasi gratuiti.

Quando invece cambi qualcosa — un interruttore, una regola, una pianificazione che scatta — il poll successivo lo raccoglie per intero. In pratica una modifica raggiunge i dispositivi client online entro circa un minuto.

(Una nota sulla fatturazione: una risposta «niente di nuovo» conta comunque come attività per il conteggio dei dispositivi attivi mensili — ma ricorda, un dispositivo conta una volta al mese indipendentemente da quanto spesso fa poll.)

La promessa di fallback

Un’interruzione di FortressFlag non deve mai buttare giù la tua app. Ogni SDK conserva gli ultimi valori ricevuti in una cache locale durevole e risolve i flag attraverso la stessa cascata:

1. Gli ultimi valori ricevuti — anche da un’esecuzione precedente. Un dispositivo rimasto offline per un mese serve ciò che ha visto l’ultima volta; meglio un dato vecchio che una regressione a sorpresa.
2. Il valore predefinito del tuo codice — quello nel punto di chiamata — quando non è mai stato ricevuto nulla. (Gli SDK client, per le letture booleane senza predefinito, si fermano a false.)

Due conseguenze che vale la pena conoscere:

• Una credenziale revocata o non funzionante non rompe la tua app. L’SDK continua a servire la sua cache e continua a riprovare. Gli errori non raggiungono mai i tuoi utenti attraverso la lettura di un flag.
• Un payload che l’SDK non riesce a verificare viene trattato come nessun payload. Ogni risposta è firmata, e l’SDK controlla la firma prima che qualcosa cambi — vedi Firma dei payload.
• Archiviare un flag lo spegne davvero. Quando un flag esce dal payload, l’SDK lo rimuove dai valori attivi e dalla cache nello stesso poll — entro circa un minuto, i dispositivi online ovunque risolvono il valore predefinito del tuo codice. La cache non conserva mai i flag rimossi — se lo facesse, archiviare non potrebbe chiudere un rollout per sempre.

Prossimi passi

• Chiavi — ffc_ contro ffs_, e perché una è pubblica e l’altra sveglia qualcuno
• Identità del dispositivo e fatturazione — cos’è l’identità del piano client
• Installa un SDK — scegli la tua piattaforma e pubblica un flag