Feature Flag¶
Contrôleur HTTP qui expose les feature flags applicatifs aux clients web et mobile, en tenant compte du groupe d'accès beta de l'investisseur et — pour mobile — de la version de l'app installée. Source : feature-flag.controller.ts.
Tous les endpoints requièrent un JWT investisseur valide (JwtAuthGuard) et le rôle CUSTOMER (UserRoleGuard).
Algorithme de résolution¶
Pour chaque flag stocké en base (feature_flag), la valeur exposée est :
Avec :
versionCompatible:truesi pas deminVersiondéfini, sinonsemver.gte(appVersion, minVersion). Pour/web,appVersionest toujoursundefineddonc cette condition est neutrehasFeatureAccess:truesi l'investisseur a au moins unfeatureFlagAccessGroup(ex.tech,bricks,drafter) inclus dans lesbetaAccessGroupsdu flag
Les flags absents en base sont par défaut renvoyés à false. Le set des clés possibles est figé par featureFlagName (cf. getFeatureFlags.endpoint.ts).
GET /feature-flag/web¶
Renvoie les feature flags pour le client web (feature-flag.controller.ts#L11). Aucune notion de version applicative côté web.
Response¶
Type : FeatureFlags. Objet plat avec une entrée booléenne par flag connu :
{
"ENABLE_PRODUCT_TRACKING": true,
"ENABLE_BUYING_BRICKS_RESERVATION": false,
"DISPLAY_GIFT_CARD_PAGE": true,
"DISPLAY_PROJECTS_PAGE": false,
"...": "..."
}
GET /feature-flag/mobile¶
Renvoie les feature flags pour le client mobile (feature-flag.controller.ts#L21) en filtrant par version d'app.
Headers¶
x-version(string) — version de l'app mobile (au format SemVer, ex.4.12.0). Comparé viasemver.gteà laminVersionéventuelle de chaque flag
Response¶
Même structure que /feature-flag/web, avec :
- chaque flag dont la
minVersionest plus récente quex-versionest renvoyé àfalse(sauf si l'investisseur appartient à un groupe beta du flag) - une clé supplémentaire
DISPLAY_LEMONWAY_ONBOARDING: falseajoutée pour compatibilité — le validateur mobile l'attend encore alors que le flag a été retiré de l'API
Liens¶
- Service :
feature-flag.service.ts - Endpoints partagés :
getFeatureFlags.endpoint.ts