Ga naar inhoud
FortressFlag Docs

Hoe flags je app bereiken

Je app belt FortressFlag niet elke keer dat hij een flag controleert. Flag-reads zijn lokaal — direct, offline-veilig, geen netwerk in het pad. Wat over het netwerk reist is een periodieke poll, en wat die poll ophaalt hangt af van op welk van de twee planes je zit.

Het client plane: je apps krijgen antwoorden, geen regels

Section titled “Het client plane: je apps krijgen antwoorden, geen regels”

De iOS-, Android- en web-SDK’s gebruiken het client plane. Het apparaat stuurt zijn identiteit en zijn tags; FortressFlag evalueert je targetingregels aan de serverkant en retourneert alleen de waarden van dat ene apparaat — een kleine map zoals {"new-checkout": true, "dark-mode": false}.

Het apparaat ontvangt je regels nooit. Dat is bewust, om twee redenen: je targetinglogica (“bètacohort”, “interne apparaten”) is jouw zaak en hoort niet te verschepen in iets dat iedereen uit een app-binary kan uitpakken — en de payload blijft piepklein.

Het client plane authenticeert met een clientsleutel (ffc_…), die in je app meegaat en publiek is by design — meer daarover in Sleutels.

Het server plane: je backend krijgt de ruleset

Section titled “Het server plane: je backend krijgt de ruleset”

De Go SDK gebruikt het server plane. Je server downloadt de volledige ruleset voor één project + omgeving — soorten, standaarden, regels, met segmenten er al in uitgevouwen — en evalueert flags in zijn eigen proces. Een flagcontrole is een functieaanroep op data die al in het geheugen staat: geen netwerkstap per controle, geen latentie per verzoek, en één poll bedient je hele proces, hoeveel verzoeken het ook afhandelt.

Omdat de ruleset je targetingregels bevat, zit dit plane achter een serversleutel (ffs_…) — een echt geheim, behandeld als een databasewachtwoord. En aangezien je regels elke server bereiken die die sleutel houdt, is het uitvloeisel aan jou om toe te passen: stop geen geheimen of persoonsgegevens van je gebruikers in regelcondities.

Op dit plane is er geen apparaatidentiteit. Je code geeft per evaluatie een contextsleutel mee — een gebruikers-ID, een sessie-ID, waar je ook op bucket — en de rollout-rekenkunde gebruikt die precies zoals het client plane het apparaat-ID gebruikt, zodat dezelfde invoer in hetzelfde cohort landt, welk plane ook evalueert.

Pollen, en waarom het goedkoop is

Section titled “Pollen, en waarom het goedkoop is”

Beide planes pollen op een interval, en beide gebruiken conditionele verzoeken: elk antwoord draagt een validator (een ETag), en wanneer er sinds de vorige poll niets is veranderd, is het antwoord een piepklein “niets veranderd” — geen body, geen her-evaluatie. De stabiele toestand van een vloot die geen flags wijzigt is een stroom bijna-gratis controles.

Wanneer je wel iets verandert — een schakeling, een regel, een schema dat afgaat — pikt de volgende poll het volledig op. In de praktijk bereikt een wijziging online clientapparaten binnen ongeveer een minuut.

(Eén factureringsnotitie: een “niets veranderd”-antwoord telt nog steeds als activiteit voor het aantal maandelijks actieve apparaten — maar onthoud, een apparaat telt één keer per maand, hoe vaak het ook polt.)

De fallback-belofte

Section titled “De fallback-belofte”

Een storing bij FortressFlag mag nooit je app neerhalen. Elke SDK bewaart de laatst ontvangen waarden in een duurzame lokale cache en resolvet flags via dezelfde cascade:

  1. De laatst ontvangen waarden — ook uit een vorige run. Een apparaat dat een maand offline is geweest serveert wat het het laatst zag; staleness verkiezen we boven verrassende regressies.
  2. De standaard van je code — de waarde op de aanroepplek — wanneer er nog nooit iets is ontvangen. (Client-SDK’s bodemen uit op false voor boolean-reads zonder standaard.)

Twee gevolgen die het weten waard zijn:

  • Een ingetrokken of falende credential breekt je app niet. De SDK blijft zijn cache serveren en blijft het proberen. Fouten bereiken je gebruikers nooit via een flag-read.
  • Een flag archiveren zet hem echt uit. Wanneer een flag de payload verlaat, laat de SDK hem in dezelfde poll uit de live waarden en de cache vallen — binnen ongeveer een minuut resolven online apparaten overal de standaard van je code. De cache bewaart verwijderde flags nooit — deed hij dat wel, dan kon archiveren een rollout niet definitief beëindigen.

Waar nu heen?

Section titled “Waar nu heen?”