Configure Strict adapter, introduce AdapterBuilder

[bkeepers]

#760 adds a Strict adapter to warn when features don't exist. This configures it by default and sets it to :warn for now. But we should change it to :raise in test/development in 2.0.

Rails.application.configure do
  config.flipper.strict = false # or :warn or :raise
end

This also adds…

AdapterBuilder

There has never really been a good way to configure the Russian doll structure of adapters. Wrapping an adapter has required re-configuring the entire stack.

This introduces a #use method that can be used to configure adapters that wrap the primary storage adapter.

Flipper.configure do |config|
  config.use Flipper::Adapters::ActiveRecordCacheStore, Rails.cache

  # This is already configured by Flipper::Engine based on FLIPPER_STRICT env var or Rails.env
  # config.use Flipper::Adapters::Strict

  # Already configured by `flipper-active_record` gem
  # config.adapter { Flipper::Adapters::ActiveRecord.new }
end

TODO:

• Add AdapterBuilder to make it easier to wrap/compose adapters
• Configure Strict by default
• Configure in Cloud

[bkeepers]

I tested this in an app that uses flipper cloud and here's the console:

$ rails console
>> Flipper.enabled?(:nopenope)
Could not find feature "nopenope". Call `Flipper.add("nopenope")` to create it.
=> false


$ FLIPPER_STRICT=true rails console
>> Flipper.enabled?(:nopenope)
/Users/bkeepers/projects/flipper/lib/flipper/adapters/strict.rb:16:in `block in <class:Strict>': Could not find feature "nopenope". Call `Flipper.add("nopenope")` to create it. (Flipper::Adapters::Strict::NotFound)

Default is warn, setting FLIPPER_STRICT to true or raise will raise errors, false will do nothing.

[jnunemaker]

This looks great.

My only concern is performance. As long as we doc heavily (add to optimizations) that people will want to use strict = false in production or we default to strict = false in production, it should be ok.

I don't think we want to look up all the features for every enabled? check. People with memoize and/or preloading off would definitely be hurt.

[bkeepers]

My only concern is performance. As long as we doc heavily (add to optimizations) that people will want to use strict = false in production or we default to strict = false in production, it should be ok.

Good call. 443742b changes the default for production to false. I'll update the optimization docs too.

[jnunemaker]

[SethHorsley]

What is the expected way to handle this in tests?

Should I add all the features in a fixture or in an initializer file for flipper?

It mentions this in the docs:

Adding feature flags to your app is as simple as adding conditionals
...

<% if Flipper.enabled? :new_feature, current_user %>
 <%= link_to "New Feature", new_feature_path %>
<% end %>

https://www.flippercloud.io/docs/guides/launch#add-feature-flags-to-your-app

It makes it seem like just adding the conditionals like Flipper.enabled? :new_feature is all you need but in tests this warns:

Could not find feature "deep_search". Call `Flipper.add("deep_search")` to create it.

[kwent]

We need more guidance for tests, it's impossible for us to upgrade flipper without rewriting some specs.

Rails.application.configure do
  config.flipper.strict = false
end

Is not working in specs context.

[SethHorsley]

this is followed up here @kwent
#807