Support feature options (strings and json) or complex conditions in getVariant

[amit-100ms]

Describe the feature request

Currently we can use getVariant but it only support OR of different conditions not more complex than that. We should support more complex conditions in getVariant.

Or simply apart from feature flags unleash should support feature options returning different values on different strategies. Currently launchdarkly supports it.

Solution suggestions

1. Complex conditions in getVariant
2. feature options (strings and json)

[thomasheartman]

Hey, @amit-100ms 🙋🏼 Thanks for making the feature request and sorry it took so long to get back to you 🙇🏼

As mentioned in Slack, I think this is a very interesting and potentially very useful feature, so I'm glad you've recorded it! It's not something we can get done in Q2, but we've recorded the issue and will consider planning it for Q3 this year.

That said, if it's something you think you might want to create and contribute to Unleash, then let me know! In that case, we can loop in more of the team and discuss what the right approach would be ☺️

[telekom-digioss]

We are thinking also in such directions about to return strings under special conditions instead of only true/false

With whom we can discuss that ?

At the moment i am thinking about a custom Strategie for that, but i am not sure if it would be good to have in unleash placed.

One use case:
Mainly we want to use as context of the request the current the name of the java class and the current global log level as input for a custom strategie.

Then we will configure on unleash a list of the javaclass first part of the name and the global current log level which should be used for the application.

The unleash entry then would be a list of "nondefault" loglevels like:

"de.tm.however.the.class.name.begins:TRACE"
"de.tm.next.class.name.begins:DEBUG"

When the request now tells as current classname in the code "de.tm.however.the.class.name.begins.MOREDEEPER" and the global log level of the application is "INFO", unleash would return "TRACE"

The logic should be coded in the custom strategy, so that the usage in the application code is really simple like for normal toggles.

This we would check everywhere where we do logging and would take the output of unleash check als log level.

And boom, we would have a possibility at runtime to configure the loglevels of the application.

If no ":" is in the list entry, then only "DEBUG" would be configured and the whole application would be switched to DEBUG logging without restarting.

This really would be an enterprise ready solution where we can configure also big applications in this way to change at runtime loglevel for all or parts of the application.

Stupid approach or have i understood the topic wrong ?

[thomasheartman]

Hey, @telekom-digioss 👋🏼 Thanks for the input!

There is actually a way to return a specific string when a toggle is enabled: you can use a feature with a single variant. It's not particularly intuitive, but it does work. That way you could do something like:

const extraData = unleash.getVariant('toggleName', context).payload.value

Addressing your actual use case, let's see if this checks out:

• You want a globally specified log level.
• For certain classes, you want to be able to override that based on input from Unleash
• If there is no override, use the global log level

You can use variants to achieve that!

If so, you could achieve that as follows:

1. Create a feature for log level (let's say we call it log-level). Assign it the default strategy so that it's always on for everyone (or use a different strategy, or constraints, to limit who gets access).
2. Create one variant without a payload. This is the default variant that every non-overridden class gets.
3. Create more variants (see next step) with a fixed weight set to 0 (so that only overrides take effect). For each variant assign the log level you want as a payload.
4. EITHER create one variant per log level and use the overrides field to list all classnames that should have this override OR create one variant per class that overrides the global log level. Add the classname as an override.

There are some limitations with this setup, most notably that variant overrides currently only support exact matches and not substring matches, but depending on your use case, it might be enough. Something like this?

Update

on thinking a bit more, it's probably easier to just create a variant for each log level. Something like this: In addition to the default variant, create one variant for each log level and use the classname in the overrides. Then, when you check it in the code, you can do something like:

const logLevel = unleash.getVariant('log-level').name

// logLevel would then be one of 'default', 'TRACE', 'DEBUG', etc

setLogLevel(logLevel)

That's probably a much better approach.

Would that work for you?

[comp615]

Wanted to leave a comment here and say that we evaluated Unleash for use, but also found it inadequate as it cannot return primitive values instead of just true/false.

I agree with the conversations above in that it should be a small pivot on variants. The idea is:

• Return a payload of any primitive (instead of just true/false; already supported)
• Allow overrides to use more complex logic for context fields (similar to the base flags UI with "in" AND NOT OR)

As you point out @thomasheartman it can basically do this already via overrides...but that does not allow for something like ordered overrides (match first of a list of sets of override rules, ex below). An additional nit is that the UI doesn't make sense in this case because a user would be purely using it for overrides.

Our use case is something like "numberOfDaysForBannerDelay"...we might want to say:

• If EU, 1
• If US AND isTestUser, 1
• If US, 7

In short, allow conditions to return values instead of just match on/off. Hope this helps!

[kwasniew]

@comp615 we are adding strategy variants support this quarter. Actually this is something we're actively working on right now :) Here's the roadmap item to track: #4204
Long story short: every strategy will resolve not just to true/false but to any value/variant. So you can use full power of constraints and segments. Basically it means that the previous variants may not be needed as they become part of strategies.
Yesterday I got it working E2E with Node SDK: Unleash/unleash-client-node#482 and it turned out to be quite easy to implement. We'd like to stabilize it in the upcoming weeks and start adding support in other SDKs. BTW what SDK do you use?

[comp615]

We'd be looking at the node/JS SDK. So exactly what you linked.

I'm a hands-on person and new to all the specific terminology here, so it's a little tough for me to grok exactly what that will look like in practice and what the changes to the server and strategy functionality are, but sounds promising! I think that's exactly what I was asking about though; will it be available for the self-hosted too?

[kwasniew]

From what I understand it it will cover the exact use case that you have. Once we have it working I will share some examples for the visual learners. And yes, from what I know it should be available for everyone.

[kwasniew]

Here's a preview of how the new strategy variants work:

255152698-27288b01-5468-4e17-a454-c63c09a0b404.1.mov

The WIP docs: https://unleash-docs-git-strategy-variants-docs-unleash-team.vercel.app/reference/feature-strategy-variants

In the video I'm using tip of main for unleash-server with strategyVariant flag enabled + latest beta version of the unleash-client-node and some old version of the unleash-proxy-client-js talking to the Frontend API (which is doing the heavy lifting so the JS client doesn't need any updates).

[adityameharia]

This feature would be really useful for us as well. Hoping its added to the go sdk soon.

[kwasniew]

@adityameharia I don't want to overpromise anything but there's a chance we'll pick up Go SDK in the second half of August.

[sjaanus]

@adityameharia It seems we won't need to wait until the second half of August after all. We've managed to finish the task ahead of schedule and have strategy variants support ready in v3.8.0.

[kwasniew]

This is now supported with the strategy variants: https://docs.getunleash.io/reference/strategy-variants