We did this. Two tables. One for feature flags, with name, desc, id, enum (none,... | Hacker News

Hacker Newsnew | past | comments | ask | show | jobs | submit

		twisteriffic 11 months ago \| parent \| context \| favorite \| on: It's OK to hardcode feature flags We did this. Two tables. One for feature flags, with name, desc, id, enum (none, defaultToEnabled, overrideToDisabled). One for user flag overrides, with flagId, userId, enum (enabled, disabled). The combination of these two has been all we've ever needed. User segmentation, A/B testing, pilot soft launch etc are all easy.

uutangohotel 11 months ago [–]

Would you mind expanding on the usage of enums for the feature flags table? Why not use a boolean?

twisteriffic 11 months ago | [–]

We actually did use booleans, I just found it easier to explain using enums, and the code would have been simpler if we'd done it that way.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact