Data Models

[vikhyat187]

Approach 1

Feature Flag

{
    "id": string,
    "flagName": string,
    "createdAt": number,
    "createdBy": string,
    "deletedAt": number,
    "description": string
}

Users (Existing)

{
  'id': string,
  'username': string,
  'first_name': string,
  'last_name': string,
  'email': string,
  'phone': number,
  'yoe': number,
  'company': string,
  'designation': string,
  'img': string,
  'github_id': string,
  'linkedin_id': string,
  'twitter_id': string,
  'instagram_id': string,
  'website': string,
  'github_display_name': string,
  'isMember': boolean,
  'userType': string,
  'tokens': {},
  'badges': []
}

FeatureFlagUserMapping

One drawback of having a separate table for user feature mapping, can be if we want to release feature X for 100 users, we need to make 100 entries in the FeatureFlagUserMapping table.

For fetching the flag of User X, need to scan all the entries with index on UserId

{
'flagId': string,
'userId': string,
'enabled': boolean
}

Approach 2: storing flags in Users

Feature Flag

{
    "id": string,
    "flagName": string,
    "createdAt": number,
    "createdBy": string,
    "deletedAt": number
}

Users (Existing)

{
  'id': string,
  'username': string,
  'first_name': string,
  'last_name': string,
  'email': string,
  'phone': number,
  'yoe': number,
  'company': string,
  'designation': string,
  'img': string,
  'github_id': string,
  'linkedin_id': string,
  'twitter_id': string,
  'instagram_id': string,
  'website': string,
  'github_display_name': string,
  'isMember': boolean,
  'userType': string,
  'tokens': {},
  'badges': [],
  **'flags': []**
}

One drawback of this approach is that if we have many feature flags for a User, the list of flags would become very large. We can fetch feature flags for Users, but the other way is not possible i.e: Fetching Users from the Feature flag.

Approach 3: Storing Users in Feature flags and Flags in Users

Feature Flag

{
    "id": string,
    "flagName": string,
    "createdAt": number,
    "createdBy": string,
    "deletedAt": number,
    "Users": []
}

Need to think more about faster querying for a user. Given a user check if the flag is enabled.

Users (Existing)

{
  'id': string,
  'username': string,
  'first_name': string,
  'last_name': string,
  'email': string,
  'phone': number,
  'yoe': number,
  'company': string,
  'designation': string,
  'img': string,
  'github_id': string,
  'linkedin_id': string,
  'twitter_id': string,
  'instagram_id': string,
  'website': string,
  'github_display_name': string,
  'isMember': boolean,
  'userType': string,
  'tokens': {},
  'badges': [],
  'flags': []
}

We have to update the data in 2 models, append the flag in flags of User model and append the User in Users of flag model.

[gauravv-dev]

Some thoughts

• Feature flag data model should have a description attribute.
• User - FF mapping is needed all times for the client side. Also required for the dashboard, when you want to search for a user and check what all feature flags are enabled for them.
• FF - User mapping is interesting and depends on where it might be used. Dashboards? Do we really want to list all the users on a particular FF ? There could be thousands. How do we effectively show them on screen? Search? why not just search using the user id then?

Instead of putting all these details in the issue, let's use wiki?

[vikhyat187]

Feature flag data model should have a description attribute.

Will add description attribute

User - FF mapping is needed at all times for the client side. Also required for the dashboard, is when you want to search for a user and check what all feature flags are enabled for them.

Yes, we want to search if the flag is enabled for the user. @ankushdharkar mentioned if we can have some way in which reading is very fast, writing can consume some time. (This is optional)

FF - User mapping is interesting and depends on where it might be used. Dashboards? Do we really want to list all the users on a particular FF? There could be thousands. How do we effectively show them on screen? Search? why not just search using the user id then?

Yes, possibly I can think of dashboards, true they can be thousands of users, let's have the scope by searching by user id for now.