Skip to content
This repository has been archived by the owner on May 30, 2024. It is now read-only.

Annotation to check if a flag is enabled or not #247

Closed
vikasgarghb opened this issue Sep 1, 2021 · 1 comment
Closed

Annotation to check if a flag is enabled or not #247

vikasgarghb opened this issue Sep 1, 2021 · 1 comment

Comments

@vikasgarghb
Copy link

vikasgarghb commented Sep 1, 2021

Is your feature request related to a problem? Please describe.
Currently, if we have to check a feature we need to define a method in the service layer where we call the LDClient and check the provided feature state. Once the service layer is defined, we need to add the feature checks in the code, for example if you want to add a check in controller, you have to add that if check everywhere. Something like,

@Controller
@RequestMapping("/xyz")
public class XYZController {
  @RequestMapping("/list")
  public List<String> getTodos() {
    if (!featureService.isFeatureEnabled("feature.key")) {
       // Throw an error or log an error.
    }
    return list;
  }
}

Describe the solution you'd like
If there was an annotation, I wouldn't have to add the if block mentioned above in every controller method. I can just do this,

@Controller
@RequestMapping("/xyz")
public class XYZController {
  @RequestMapping("/list")
  @CheckFeatureFlag("feature.key")
  public List<String> getTodos() {
    return list;
  }
}

And then the annotation can be handled by either an Interceptor OR an AspectJ based solution.

Describe alternatives you've considered
None.

Additional context
Add any other context about the feature request here.

@bwoskow-ld
Copy link
Member

Hi @vikasgarghb,

Thanks for the feature request. This is an interesting idea. However, I'm not sure that we can design such an annotation in a way that would be flexible enough to warrant an addition to our SDK:

  1. The example works well for boolean feature flags but becomes more complex for multivariate flags. For example, if a flag was of type number or string, the annotation would have to know (e.g. by an additional parameter) which variation represented "enablement" or "disablement". Additionally, with non-boolean flags, there are often multiple levels of enablement across various variations.
  2. Your example expects that all "disabled" code would exhibit the same behavior when invoked, and that this behavior would be baked into the annotation. This is difficult as different customers would want different behavior; I'm not sure what would be a one-size-fits-all solution that would work for all customers and across all of each customers' use cases.

All in all, I think this is an interesting idea, but one that would be most appropriate for you to implement on your side to most closely match your business needs. If you come up with a solution, we'd love for you to share what you have implemented so that other developers can use it as inspiration.

Cheers,
@bwoskow-ld

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants