Swapping flag state "backend"

Created on 19 April 2024, 7 months ago
Updated 30 April 2024, 7 months ago

Problem/Motivation

I'm not using this module (yet), but evaluating it.
I have a usecase where this could fit, but flag state needs to be persistent, so state might not be a good solution. I just don't want that to be regular config for different reasons.

I could swap the FlagManager service with my own (e.g. something using ConfigPages module for storing the flag states? an environment variable?), It might be even an option to even have different FlagBackendStorage? (name to be defined) per flag.

Wondering if it would be useful having a FlagBackendStorage or alike, or I'm overcomplicating things.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

✨ Feature request
Status

Active

Version

2.0

Component

Code

Created by

πŸ‡ͺπŸ‡ΈSpain penyaskito Seville πŸ’ƒ, Spain πŸ‡ͺπŸ‡Έ, UTC+2 πŸ‡ͺπŸ‡Ί

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @penyaskito
  • πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10

    I'm open to swapable storage

    Linking some core issues where it has been decided that ::moduleExists is really all we need for feature flags - but I recognise that's using config which you said you didn't want to use.

    That's the same reason for this module existing, client has N sites with common code base and needs to make content changes after deploying new version before turning on new features.

  • πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10

    Chatted on slack with @penyaskito - it looks like we have a flag manager service for caching (which is now in core for state so is probably redundant) - but we can keep it there and you can swap that out

Production build 0.71.5 2024