[vemv]

Haven't tried it myself, but why not use authorization libraries instead of specialized 'toggle' libraries?

After all, both are concered with whether user X is allowed to do Y.

Using just one approach might be a clean, maintainable approach.

The original code `if can?(:use_feature_x, user)` is written just once, and then never needed to be removed. The only thing that changes, gradually and cleanly, are the business rules in :use_feature_x (e.g. update the method in your ability.rb, using Ruby CanCan terminology)

[pkaeding]

In canary launches, you might want to roll a new feature out to 10% of your users, then 20%, etc. Once it is released to 100% of your users, you might want to remove the check, since it is a no-op.

I'm not aware of any authorization libraries that let you grant access to a percentage of your users, but maybe they are out there? It is a strange use case from an 'authorization' standpoint.

[vemv]

no-op point is true (except for logged out users - then the check is still useful)

Anyway, how do you consistently decide to which 10% you show the new feature?

That piece of data is better stores in your Users table, as I see it. Plays well with authorization libs.

[pkaeding]

The way LaunchDarkly does it is to hash the user key, along with the feature key. This way the same users aren't always included in the '10% set' for all features, but they are consistently in the 10% set for a single feature.

This also allows the decision to be made in memory, without an additional round-trip to the DB.