-
-
Notifications
You must be signed in to change notification settings - Fork 220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add feature flagging #56
Comments
Just curious on your approach here: Are you referring to having different features of this starter repo be able to be turned on and off, like a create-react-app style config tool? Or feature flags at the application level, where feature flags might be stored in the database and loaded using Apollo (and perhaps provided throughout the app as context... is this a good idea btw, or should Apollo just always be used)? |
Application level feature flags to help with continuous delivery. Two classes: one where it’s toggleable per user (opt-in to alpha/beta features), and one where it’s system-wide (with partial roll-out). |
Ah, I understand. Partial roll-out seems like an interesting concept to me. Would be very curious to see how that is implemented. I recently implemented feature flags in my main codebase (not based on the starter, but similar) and I did it at three levels: at the user-level, at an organization-level, and at the system-level. I might be able to help with some of the UI design of this if you need a hand. |
@benjie Would be interested in how you are imagining this work. I will be writing something very basic to rollout 'beta' features so could do it 'properly' and implement this. I have had a think.. One way might be to build a table for 'flagged features' and then obviously a junction table. Something like; Features: id, Uname(perhaps), desc _Could add fields: UserFeatureflags: feature_id, user_id _Could add table: A developer can then gate code however they want. E.g he could gate behind currentuser.userfeatureflags featureid or perhaps (if we include it in the schema etc) the feature Uname. I personally prefer to do it based on ID as that is explicit and a less expensive query (although less of an issue if they query once per session rather than once per view or build a map on login), but I can see that it is worse in terms of readability and developer friendliness. We could include: If we then want to extend to organization-level, we could either move to either using a user_features and org_features junction table or putting an org_id field in a single generic featureflags table and dealing with the logic in the SQL functions. Personally I would prefer the multiple junction tables. The developer then decides how to gate features. For example, they may decide to do: if current user has flag || any orgs they are a member of has flag, or if it is a feature that is org specific only they may simply test if the current org has the flag (or if it is only user specific then user only). |
I've not really thought about it in depth, but what I've done in the past was less database-centric. Defaults would be set with a config file under source control: // All flags:
export enum Flags {
ORGANIZATION_DELETION = 'ORGANIZATION_DELETION';
FILE_UPLOADS = 'FILE_UPLOADS';
...
}
// Just the flags enabled by default:
export default flags = [
Flags.ORGANIZATION_DELETION,
...
]; You can then gate features using these enum values (and be sure you're not making typos anywhere). Global feature flags could be toggled via a feature flag string stored in an environmental variable:
Each flag is either toggled on Then individual users, organizations, whatever, can have their own feature flag strings in the database, probably somewhere that only sysadmins can tweak, allowing for A/B testing, partial roll-out, etc. They'd just be strings and the database wouldn't really care about them at all. |
No description provided.
The text was updated successfully, but these errors were encountered: