Grabbing flag descriptions?

[csteez]

Hi!
We use LaunchDarkly to manage feature rollouts. We're updating to the newest version of this gem since the version we were using is quite old and seems to use an API which no longer exists. In the old gem, there was a way to get the descriptions of the features. Is there a way to get that with this version of the gem? Or perhaps with a more recent but not deprecated version of the gem?
Thanks!

[eli-darkly]

Hi - I'm not sure which SDK method you're referring to. Can you tell me what version of the gem you were using previously?

[csteez]

We were on v 0.6.x before, but the update function(toggle?) no longer works so I'm trying to upgrade.
We forked off the SDK at around late 2015.

Does that help?

[csteez]

Am I reading this right that Variation doesn't let you update the flag variation?

[eli-darkly]

We were on v 0.6.x before

OK... I'm guessing that you were using the get_features method. Indeed, there's no longer an equivalent to this in ldclient-rb; the SDK now hides the details of the flag data model, giving you only the flag value.

For getting further details on flags, you will need to access the lower-level REST API, described here. We have an OpenAPI spec and have generated a basic client library from it; we haven't released that yet, but we can put out a beta.

Am I reading this right that Variation doesn't let you update the flag variation?

If by update you mean modify the flag so it will return a different value - no, the SDK doesn't do that. If you need to do it programmatically, again you'll have to use the lower-level API.

[csteez]

Would updates be supported in the beta? How long would it take to get the beta version?

[eli-darkly]

It does support updating feature flag properties, and I'll include an example of that in the readme file once we release the code - which should be today or tomorrow. I'll comment here when it's available.

[eli-darkly]

@csteez - We've made the OpenAPI client public here, and it's been published to RubyGems. I went ahead and made it a regular release rather than a beta, but you're the first to use it so we'd love to get feedback on whether this Swagger-generated code is in fact convenient to use.

The readme in that repo includes examples of both getting a feature flag description and modifying a property of a flag. I don't know which properties you're intending to modify, so in that example it's just the "on" field.

[csteez]

Ok awesome, I'll check it out. We just want the ability to update the value on a feature flag for a user, which was in the beta version of the gem.

Just a quick question, is the 'api_key' mentioned in the documentation for the open api the sdk key or the PAT referred to on the v2 documentation? We aren't able to get a PAT until we update, and I'm under the impression migrating to 'v2' will break our existing functionality.

I'm a bit confused as to what the difference is between the intended use of this sdk vs the open api implementation. clearly the open api has more functions available, so what's the intended use of this sdk?
it seems like the sdk caches values, but what else?

[eli-darkly]

is the 'api_key' mentioned in the documentation for the open api the sdk key or the PAT referred to on the v2 documentation? We aren't able to get a PAT until we update

Oh - my apologies, I wasn't familiar with the status of your account and didn't realize you are currently on v1. The API client I just published is for the v2 API - we didn't generate one for v1. I need to consult with support to see how we should approach this; let's work out the rest via the support channel, if that's OK. I'm sorry that this didn't turn out to be as straightforward as I made it sound.

I'm a bit confused as to what the difference is between the intended use of this sdk vs the open api implementation. clearly the open api has more functions available, so what's the intended use of this sdk?

The SDK's whole reason for being is to evaluate feature flags. It contains a mechanism for getting the latest flag data for a given environment, the logic for evaluating flags, and an analytics event pipeline. It is authenticated with an SDK key, which is specific to one project and environment.

The API that this new OpenAPI client uses is the same one that drives the LaunchDarkly website front end. So it lets you do programmatically the kinds of things you can do manually on the LD site: creating and modifying feature flags, user segments, goals, etc. It is authenticated with an API access token, which is for your whole account but can be configured to only allow certain operations.

The reasons they're separate are:

1. It keeps the SDK relatively lightweight, by not including the full application control functionality that most apps don't use (and by not using the bandwidth it would take to deliver the entire flag data model, rather than the flags for the current environment).
2. It keeps the SDK interface very simple. You don't need to retrieve a flag, check for updates on the flag, and then apply its rules; you just give the SDK a flag key and a user object and you get back a value.
3. They are versioned separately; updates to the LD application API do not require any SDK usage changes and vice versa.
4. They don't necessarily talk to the same server: SDK operations can be proxied through an ld-relay instance.

I hope that makes things clearer. I'll continue to follow up through support to figure out what your migration path will look like.

[csteez]

I'll contact support again for suggestions on a migration plan. Sorry I didn't mention we were on v1 still.
Thanks so much for explaining the difference! That helps making decisions a lot easier.

For our purpose, we'll definitely have to use some version of the API as the SDK doesn't really our needs.

Thanks for all your help!