Bulk Import support for flags

[shetty-tejas]

Since there's AR support available for Flipper, I think it'd be a great idea to also add support for bulk importing flags to application, something similar to what activerecord-import provides.

A use case which I think is valid would be to seed flags on application boot, as the current implementation would have N db queries for N flags.

The flavour could also be something specific to Flipper (ex. Flipper.import_enabled(flags)) or something generic (ex. Flipper.import(flags, enabled = true))

Thoughts?

[jnunemaker]

Hi @shettytejas,

Have you seen the import/export stuff? I just created a quick example of how to mirror one environment (production) to another (staging) and then back to staging.

https://github.com/jnunemaker/flipper/blob/main/examples/mirroring.rb

Check it out and see if that makes sense. This could be used for seeding by doing this:

seed = Flipper.new(Flipper::Adapters::Memory.new)
seed.enable(:search)
seed.enable_percentage_of_time(:verbose_logging, 5)
seed.enable_percentage_of_actors(:new_feature, 5)
seed.enable_actor(:issues, Flipper::Actor.new('1'))
seed.enable_actor(:issues, Flipper::Actor.new('2'))
seed.enable_group(:request_tracing, :staff)

Flipper.import(seed.export)

[shetty-tejas]

@jnunemaker Thank you for your response bro 😄 ! While I'm aware of Flipper's import and export methods, my use case involves seeding data during application boot to automate the process of setting feature flags after each deployment. Additionally, this approach enables more dynamic flags, such as controlling some edge-rails features based on the version of gem available in the Gemfile.

Currently, I have implemented a solution by creating a YAML file with flag names and boolean values and using YAML.safe_load and Flipper.send to enable or disable flags based on the values in the file. However, this approach generates N+1 queries.

I believe that the approach of using YML (or any other file for that matter) to seed feature flags during application deployment is valuable for automating the process and enabling dynamic control on the features, but it could be improved to avoid the issue of generating N+1 queries.

[jnunemaker]

@shettytejas agreed. I have some internal notes to do fewer network calls for imports. I'll leave this open as a public issue in case anyone else wants to take stab at it first. Thanks for bringing this up!