5 ms·

I agree that feature flags, like any tool, should only be used where it makes sense. I disagree that they should only be used for visual changes though. Often

I agree that feature flags, like any tool, should only be used where it makes sense. I disagree that they should only be used for visual changes though. Often, backend changes can have performance impacts that are only visible at scale, so being able to roll something out gradually can help there. Also, a flag can be used as a permanent control to disable a part of the system (like an external call) if that part of the system is having problems. Imagine if you had a github activity feed integration, and you wanted to be able disable that feature when a github outage caused that call to take a very long time. Being able to easily disable that feature without needing to change your code can be immensely useful. nb- I work for LaunchDarkly.

lantastic 10y ago
What are the situations where you did not (or would not) opt to use feature flags?
- pkaeding 10y ago
  I usually skip feature flags for things like bug fixes where the risk that my 'fix' is actually worse than the initial bug is very small, or changes where it cannot make sense to have both modes operating at once. An example of this might be a new billing scheme, where the old system billed by the item, and the new system billed by the pound. There might not be a technical reason why both cannot co-exist, but it would cause marketing/support headaches to have some customers billed one way, and some billed another. One surprising use case that I have had great success with, though, is in database migrations. I detailed my approach here, if you are interested: http://blog.launchdarkly.com/feature-flagging-to-mitigate-risk-in-database-migration/ http://blog.launchdarkly.com/feature-flagging-to-mitigate-ri...
  - lantastic 10y ago
    Interesting, thanks for the link!
    - pkaeding 10y ago
      No problem! If you happen to be in the SF Bay area (and if you will forgive the self-promotion) I'm going to be presenting this at a meetup in a couple weeks: http://www.meetup.com/AWS-EASTBAY/events/232870012/ http://www.meetup.com/AWS-EASTBAY/events/232870012/
yclept 10y ago
How exactly does the api work? Is every call to check a flag making a HTTP request to LD or does the ld client sync periodically?
- pkaeding 10y ago
  No, every call to check a flag is not making any sort of network connection. The flag ruleset (includes details like specific users that should get each variation, or particular user attributes that should indicate a specific variation, or a percentage rollout) is streamed to the SDK in a long-lived background connection. The SDK maintains these rulesets in memory, and when you need to evaluate a flag for a given user, the ruleset is evaluated. This way, there is no I/O at the time that a rule is evaluated, so there is no real performance impact. At the same time, because of the way we stream the rulesets to the SDK, any rule changes take effect immediately. https://launchdarkly.com/performance.html https://launchdarkly.com/performance.html has some diagrams, etc, detailing this (sorry for the marketing fluff :)
  - yclept 10y ago
    Great, we will be looking at applying this in a new project of ours, and replace our existing feature flag implementations in other systems if things work out.

lantastic 10y ago

What are the situations where you did not (or would not) opt to use feature flags?

pkaeding 10y ago
I usually skip feature flags for things like bug fixes where the risk that my 'fix' is actually worse than the initial bug is very small, or changes where it cannot make sense to have both modes operating at once. An example of this might be a new billing scheme, where the old system billed by the item, and the new system billed by the pound. There might not be a technical reason why both cannot co-exist, but it would cause marketing/support headaches to have some customers billed one way, and some billed another. One surprising use case that I have had great success with, though, is in database migrations. I detailed my approach here, if you are interested: http://blog.launchdarkly.com/feature-flagging-to-mitigate-risk-in-database-migration/ http://blog.launchdarkly.com/feature-flagging-to-mitigate-ri...
- lantastic 10y ago
  Interesting, thanks for the link!
  - pkaeding 10y ago
    No problem! If you happen to be in the SF Bay area (and if you will forgive the self-promotion) I'm going to be presenting this at a meetup in a couple weeks: http://www.meetup.com/AWS-EASTBAY/events/232870012/ http://www.meetup.com/AWS-EASTBAY/events/232870012/

yclept 10y ago

How exactly does the api work? Is every call to check a flag making a HTTP request to LD or does the ld client sync periodically?

pkaeding 10y ago
No, every call to check a flag is not making any sort of network connection. The flag ruleset (includes details like specific users that should get each variation, or particular user attributes that should indicate a specific variation, or a percentage rollout) is streamed to the SDK in a long-lived background connection. The SDK maintains these rulesets in memory, and when you need to evaluate a flag for a given user, the ruleset is evaluated. This way, there is no I/O at the time that a rule is evaluated, so there is no real performance impact. At the same time, because of the way we stream the rulesets to the SDK, any rule changes take effect immediately. https://launchdarkly.com/performance.html https://launchdarkly.com/performance.html has some diagrams, etc, detailing this (sorry for the marketing fluff :)
- yclept 10y ago
  Great, we will be looking at applying this in a new project of ours, and replace our existing feature flag implementations in other systems if things work out.