3 ms·
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
by vemv 10y ago
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 10y agoIn 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 10y agono-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 10y agoThe 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.