|
| 1 | +# Feature Flags |
| 2 | + |
| 3 | +Feature flags allow you to conditionally enable or disable functionality in the Unraid API. This is useful for gradually rolling out new features, A/B testing, or keeping experimental code behind flags during development. |
| 4 | + |
| 5 | +## Setting Up Feature Flags |
| 6 | + |
| 7 | +### 1. Define the Feature Flag |
| 8 | + |
| 9 | +Feature flags are defined as environment variables and collected in `src/consts.ts`: |
| 10 | + |
| 11 | +```typescript |
| 12 | +// src/environment.ts |
| 13 | +export const ENABLE_MY_NEW_FEATURE = process.env.ENABLE_MY_NEW_FEATURE === 'true'; |
| 14 | + |
| 15 | +// src/consts.ts |
| 16 | +export const FeatureFlags = Object.freeze({ |
| 17 | + ENABLE_NEXT_DOCKER_RELEASE, |
| 18 | + ENABLE_MY_NEW_FEATURE, // Add your new flag here |
| 19 | +}); |
| 20 | +``` |
| 21 | + |
| 22 | +### 2. Set the Environment Variable |
| 23 | + |
| 24 | +Set the environment variable when running the API: |
| 25 | + |
| 26 | +```bash |
| 27 | +ENABLE_MY_NEW_FEATURE=true unraid-api start |
| 28 | +``` |
| 29 | + |
| 30 | +Or add it to your `.env` file: |
| 31 | + |
| 32 | +```env |
| 33 | +ENABLE_MY_NEW_FEATURE=true |
| 34 | +``` |
| 35 | + |
| 36 | +## Using Feature Flags in GraphQL |
| 37 | + |
| 38 | +### Method 1: @UseFeatureFlag Decorator (Schema-Level) |
| 39 | + |
| 40 | +The `@UseFeatureFlag` decorator conditionally includes or excludes GraphQL fields, queries, and mutations from the schema based on feature flags. When a feature flag is disabled, the field won't appear in the GraphQL schema at all. |
| 41 | + |
| 42 | +```typescript |
| 43 | +import { UseFeatureFlag } from '@app/unraid-api/decorators/use-feature-flag.decorator.js'; |
| 44 | +import { Query, Mutation, ResolveField } from '@nestjs/graphql'; |
| 45 | + |
| 46 | +@Resolver() |
| 47 | +export class MyResolver { |
| 48 | + |
| 49 | + // Conditionally include a query |
| 50 | + @UseFeatureFlag('ENABLE_MY_NEW_FEATURE') |
| 51 | + @Query(() => String) |
| 52 | + async experimentalQuery() { |
| 53 | + return 'This query only exists when ENABLE_MY_NEW_FEATURE is true'; |
| 54 | + } |
| 55 | + |
| 56 | + // Conditionally include a mutation |
| 57 | + @UseFeatureFlag('ENABLE_MY_NEW_FEATURE') |
| 58 | + @Mutation(() => Boolean) |
| 59 | + async experimentalMutation() { |
| 60 | + return true; |
| 61 | + } |
| 62 | + |
| 63 | + // Conditionally include a field resolver |
| 64 | + @UseFeatureFlag('ENABLE_MY_NEW_FEATURE') |
| 65 | + @ResolveField(() => String) |
| 66 | + async experimentalField() { |
| 67 | + return 'This field only exists when the flag is enabled'; |
| 68 | + } |
| 69 | +} |
| 70 | +``` |
| 71 | + |
| 72 | +**Benefits:** |
| 73 | +- Clean schema - disabled features don't appear in GraphQL introspection |
| 74 | +- No runtime overhead for disabled features |
| 75 | +- Clear feature boundaries |
| 76 | + |
| 77 | +**Use when:** |
| 78 | +- You want to completely hide features from the GraphQL schema |
| 79 | +- The feature is experimental or in beta |
| 80 | +- You're doing a gradual rollout |
| 81 | + |
| 82 | +### Method 2: checkFeatureFlag Function (Runtime) |
| 83 | + |
| 84 | +The `checkFeatureFlag` function provides runtime feature flag checking within resolver methods. It throws a `ForbiddenException` if the feature is disabled. |
| 85 | + |
| 86 | +```typescript |
| 87 | +import { checkFeatureFlag } from '@app/unraid-api/utils/feature-flag.helper.js'; |
| 88 | +import { FeatureFlags } from '@app/consts.js'; |
| 89 | +import { Query, ResolveField } from '@nestjs/graphql'; |
| 90 | + |
| 91 | +@Resolver() |
| 92 | +export class MyResolver { |
| 93 | + |
| 94 | + @Query(() => String) |
| 95 | + async myQuery( |
| 96 | + @Args('useNewAlgorithm', { nullable: true }) useNewAlgorithm?: boolean |
| 97 | + ) { |
| 98 | + // Conditionally use new logic based on feature flag |
| 99 | + if (useNewAlgorithm) { |
| 100 | + checkFeatureFlag(FeatureFlags, 'ENABLE_MY_NEW_FEATURE'); |
| 101 | + return this.newAlgorithm(); |
| 102 | + } |
| 103 | + |
| 104 | + return this.oldAlgorithm(); |
| 105 | + } |
| 106 | + |
| 107 | + @ResolveField(() => String) |
| 108 | + async dataField() { |
| 109 | + // Check flag at the start of the method |
| 110 | + checkFeatureFlag(FeatureFlags, 'ENABLE_MY_NEW_FEATURE'); |
| 111 | + |
| 112 | + // Feature-specific logic here |
| 113 | + return this.computeExperimentalData(); |
| 114 | + } |
| 115 | +} |
| 116 | +``` |
| 117 | + |
| 118 | +**Benefits:** |
| 119 | +- More granular control within methods |
| 120 | +- Can conditionally execute parts of a method |
| 121 | +- Useful for A/B testing scenarios |
| 122 | +- Good for gradual migration strategies |
| 123 | + |
| 124 | +**Use when:** |
| 125 | +- You need conditional logic within a method |
| 126 | +- The field should exist but behavior changes based on the flag |
| 127 | +- You're migrating from old to new implementation gradually |
| 128 | + |
| 129 | +## Feature Flag Patterns |
| 130 | + |
| 131 | +### Pattern 1: Complete Feature Toggle |
| 132 | + |
| 133 | +Hide an entire feature behind a flag: |
| 134 | + |
| 135 | +```typescript |
| 136 | +@UseFeatureFlag('ENABLE_DOCKER_TEMPLATES') |
| 137 | +@Resolver(() => DockerTemplate) |
| 138 | +export class DockerTemplateResolver { |
| 139 | + // All resolvers in this class are toggled by the flag |
| 140 | +} |
| 141 | +``` |
| 142 | + |
| 143 | +### Pattern 2: Gradual Migration |
| 144 | + |
| 145 | +Migrate from old to new implementation: |
| 146 | + |
| 147 | +```typescript |
| 148 | +@Query(() => [Container]) |
| 149 | +async getContainers(@Args('version') version?: string) { |
| 150 | + if (version === 'v2') { |
| 151 | + checkFeatureFlag(FeatureFlags, 'ENABLE_CONTAINERS_V2'); |
| 152 | + return this.getContainersV2(); |
| 153 | + } |
| 154 | + |
| 155 | + return this.getContainersV1(); |
| 156 | +} |
| 157 | +``` |
| 158 | + |
| 159 | +### Pattern 3: Beta Features |
| 160 | + |
| 161 | +Mark features as beta: |
| 162 | + |
| 163 | +```typescript |
| 164 | +@UseFeatureFlag('ENABLE_BETA_FEATURES') |
| 165 | +@ResolveField(() => BetaMetrics, { |
| 166 | + description: 'BETA: Advanced metrics (requires ENABLE_BETA_FEATURES flag)' |
| 167 | +}) |
| 168 | +async betaMetrics() { |
| 169 | + return this.computeBetaMetrics(); |
| 170 | +} |
| 171 | +``` |
| 172 | + |
| 173 | +### Pattern 4: Performance Optimizations |
| 174 | + |
| 175 | +Toggle expensive operations: |
| 176 | + |
| 177 | +```typescript |
| 178 | +@ResolveField(() => Statistics) |
| 179 | +async statistics() { |
| 180 | + const basicStats = await this.getBasicStats(); |
| 181 | + |
| 182 | + try { |
| 183 | + checkFeatureFlag(FeatureFlags, 'ENABLE_ADVANCED_ANALYTICS'); |
| 184 | + const advancedStats = await this.getAdvancedStats(); |
| 185 | + return { ...basicStats, ...advancedStats }; |
| 186 | + } catch { |
| 187 | + // Feature disabled, return only basic stats |
| 188 | + return basicStats; |
| 189 | + } |
| 190 | +} |
| 191 | +``` |
| 192 | + |
| 193 | +## Testing with Feature Flags |
| 194 | + |
| 195 | +When writing tests for feature-flagged code, create a mock to control feature flag values: |
| 196 | + |
| 197 | +```typescript |
| 198 | +import { vi } from 'vitest'; |
| 199 | + |
| 200 | +// Mock the entire consts module |
| 201 | +vi.mock('@app/consts.js', async () => { |
| 202 | + const actual = await vi.importActual('@app/consts.js'); |
| 203 | + return { |
| 204 | + ...actual, |
| 205 | + FeatureFlags: { |
| 206 | + ENABLE_MY_NEW_FEATURE: true, // Set your test value |
| 207 | + ENABLE_NEXT_DOCKER_RELEASE: false, |
| 208 | + } |
| 209 | + }; |
| 210 | +}); |
| 211 | + |
| 212 | +describe('MyResolver', () => { |
| 213 | + it('should execute new logic when feature is enabled', async () => { |
| 214 | + // Test new behavior with mocked flag |
| 215 | + }); |
| 216 | +}); |
| 217 | +``` |
| 218 | + |
| 219 | +## Best Practices |
| 220 | + |
| 221 | +1. **Naming Convention**: Use `ENABLE_` prefix for boolean feature flags |
| 222 | +2. **Environment Variables**: Always use uppercase with underscores |
| 223 | +3. **Documentation**: Document what each feature flag controls |
| 224 | +4. **Cleanup**: Remove feature flags once features are stable and fully rolled out |
| 225 | +5. **Default State**: New features should default to `false` (disabled) |
| 226 | +6. **Granularity**: Keep feature flags focused on a single feature or capability |
| 227 | +7. **Testing**: Always test both enabled and disabled states |
| 228 | + |
| 229 | +## Common Use Cases |
| 230 | + |
| 231 | +- **Experimental Features**: Hide unstable features in production |
| 232 | +- **Gradual Rollouts**: Enable features for specific environments first |
| 233 | +- **A/B Testing**: Toggle between different implementations |
| 234 | +- **Performance**: Disable expensive operations when not needed |
| 235 | +- **Breaking Changes**: Provide migration path with both old and new behavior |
| 236 | +- **Debug Features**: Enable additional logging or debugging tools |
| 237 | + |
| 238 | +## Checking Active Feature Flags |
| 239 | + |
| 240 | +To see which feature flags are currently active: |
| 241 | + |
| 242 | +```typescript |
| 243 | +// Log all feature flags on startup |
| 244 | +console.log('Active Feature Flags:', FeatureFlags); |
| 245 | +``` |
| 246 | + |
| 247 | +Or check via GraphQL introspection to see which fields are available based on current flags. |
0 commit comments