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

Retrieve all variations for a flag #161

Closed
zacyang opened this issue May 10, 2019 · 4 comments
Closed

Retrieve all variations for a flag #161

zacyang opened this issue May 10, 2019 · 4 comments

Comments

@zacyang
Copy link

zacyang commented May 10, 2019

I needed a test to verify that the constant default in the code base (java) is compatible with the given values (json array) on the server.

Describe the solution you'd like
Create a separate method in the client which can retrieve all the variations associated with a feature key.

Describe alternatives you've considered
Currently I have to use REST endpoint to request and parse the variations my self, as the LDClient is final.

@bwoskow-ld
Copy link
Member

Hi zacyang,

Thanks for the suggestion. This is a low priority at the moment since we don't believe this feature request to be something that would be generally useful to most customers, but we'll keep this issue for future consideration.

Ben

@eli-darkly
Copy link
Contributor

It'd be easier to determine the best approach to this if the use case was clearer. This is something that could only be done when you have a live connection to LaunchDarkly - so, when you say "I needed a test", do you mean you would have a unit test or integration test that would actually connect to LD? Generally speaking it's not advisable to have CI tests like this rely on an external service. Or would this be something that is used in production by your application?

It sounds like whichever context you want this in, you are already doing it now via your REST workaround so I'm sure you're already aware of the tradeoffs, but I'd just like to understand the intended usage better.

@zacyang
Copy link
Author

zacyang commented Aug 2, 2019

@eli-darkly , thanks for getting back to me.

Yes, we used a live connection to live LD in CI. Reason for this is, we have some feature switch based on variant. The value in the variants determine the behaviours of some particular actions,
e.g ["db", "kafka"] means event A need to be save to both database and publish to kafka.

This is critical for us to guarantee the semantics (exactly once) of the events, therefor I need some test to make sure the variants are what we think it is before deploying to prod.

And you are right, I've implemented the test based on the rest api you guys provided, just thought it would be nicer to have it thru client.

eli-darkly added a commit that referenced this issue Apr 30, 2020
(5.0 - #3) rename FeatureStore and UpdateProcessor
@bwoskow-ld
Copy link
Member

Hi @zacyang ,

After re-reading this ticket, I realize that we had a solution for you all along. We maintain a set of client libraries for interacting with LaunchDarkly's REST API. These clients are auto-generated from our OpenAPI spec. Most relevant here is api-client-java.

Once you add api-client-java to your application you can use FeatureFlagsApi#getFeatureFlag(string) to get your flag and then call getVariations on the flag to get all possible variations. This is our recommended approach for doing so programmatically through a LaunchDarkly-provided client library.

The reason for maintaining API client libraries separate from our SDKs (java-server-sdk and others) is to allow our SDKs to be as lightweight as possible. We generally only add functionality to the SDKs when the functionality is common and/or crucial to the flow of evaluating flag rulesets on behalf of users, sending events back to LaunchDarkly, and so forth. All other functionality should be accessed through our REST APIs by our auto-generated API client libraries.

I'm going to close this ticket now. Cheers,
Ben

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

No branches or pull requests

3 participants