Add feature flagging

[benjie]

No description provided.

[hcharley]

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)?

[benjie]

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).

[hcharley]

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.

[MP70]

@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
//"74293c12-90c1-2da2-81e0-39c2bc10b9bb", "edit_order", "enables editing of orders"

_Could add fields:
org_feature (0/1), user_feature (0/1), user_selectable (0/1), is_beta (0/1)
// First two would enable features only relatable to orgs/users to be validated/enforced. user_selectable if 1 would allow users/org owners to enable the feature via settings page - or if 0 user/org should only have the feature enabled by site admin/business logic (i.e orgs pay per feature, or user is enrolled in beta program). is_beta could enable warning modal when toggled by user _

UserFeatureflags: feature_id, user_id
// "74293c12-90c1-2da2-81e0-39c2bc10b9bb", "99293c12-90c1-2da2-81e0-39c2bc10b9aa"

_Could add table:
OrgFeatureflags
// as below

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:
-example gated feature implementation but explain that they can choose how to gate based on thier business logic.
-postgres function around enrolling a user/org in a feature (and removing)
and maybe
-a UI in user settings to enable/disable features:
SELECT features.Uname, features.desc WHERE User_feature = 1 AND user_selectable =1; (to build the feature list, then allow toggle in the ui)
-a UI in company settings viewable by company owner to enable/disable features company wide.
SELECT features.Uname, features.desc WHERE org_feature = 1 AND user_selectable =1; (to build the feature list, then allow toggle in the ui. Gate all that behind user is org.owner)
-a node 'wrapper' script around adding a feature, enrolling a user/org in a feature.

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).

[benjie]

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:

FEATURE_FLAGS="+FILE_UPLOADS,-ORGANIZATION_DELETION"

Each flag is either toggled on + or off -, and if not present then the defaults kick in.

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.