I'm currently implementing feature flags with Azure App Config and I'm wrestling with whether or not to include default states. In my previous projects, we often didn't include defaults, but since I'm setting things up this time around, I'm contemplating it seriously. One side of the argument is that Azure's paid service claims a 99% uptime, making it seem unnecessary to add complexity just for the few instances it might fail. However, I worry that without defaults, the app could start functioning in confusing ways. While I'd be able to check the service status if it goes down, the user experience would definitely suffer. I'm only dealing with straightforward true/false flags here—no complex rollout strategies. How do you typically handle defaults in feature flags?
1 Answer
It's absolutely a good idea to set defaults in your code. Sure, 99% uptime sounds decent, but when you calculate it, that's still over 3 days of potential downtime each year. Even with Azure's reliability, you could face network issues or transient errors. What I do is initialize my feature flags like this:
```javascript
const featureFlags = {
newFeature: getFlag('newFeature') ?? false,
experimentalUI: getFlag('experimentalUI') ?? false
}
```
For boolean flags, it's safer to default to false for new or risky features—this way, if something does go wrong, users won't see errors all over the place. Plus, it simplifies local development since you won't need to connect to Azure just to run the app.
What exactly does your getFlag function do?