Feature flagging solution integration

Integrations
, , , , ,
#1

Hello
We are in the process of integration with https://launchdarkly.com/ as a feature flagging tool and was wondering if anybody has implementing the same and have for example, journeys react based on the flags.
Java SDK reference…_gaMTc0MzM3MTUxMi4xNjkxNDMyOTkz*_ga_31EH4XPW51*MTY5MTQzMjk5Mi4xLjEuMTY5MTQzMzA3OC4wLjAuMA…

The SDK library can be imported as a dependency into the application, and clients can be created within code.

Once integrated, the client can be whitelisted to be available in scripted nodes, for example.

And when the application terminates the clients need to be closed. Is there a recommendation on how this can be achieved.

Thank you

#2

Hi Nathan,

I don’t know much about this library, but I suspect it could have some initialisation code, providing some sort of root object from where the service is invoked. Doing such initialisation at each journey invocation can be consuming, so it has to be properly integrated using Guice injection, which is also the way you would inject a Singleton object, or implement caching, and so on. See : Inject objects into a node instance :: AM 7.3.0

Can you explain what you mean by “when the application terminates?”.

Regards
Patrick

1 Like
#3

Hi Patrick,
Thank you for the response,

Launchdarkly mentions the following about the integration within a java application.

  1. Add dependency for the sdk jars
<dependency>
  <groupId>com.launchdarkly</groupId>
  <artifactId>launchdarkly-java-server-sdk</artifactId>
  <version>6.0.0</version>
</dependency>

// or in Gradle:
implementation group: 'com.launchdarkly', name: 'launchdarkly-java-server-sdk', version: '6.0.0'
  1. Import the necessary jars
import com.launchdarkly.sdk.*;
import com.launchdarkly.sdk.server.*;
  1. Create a shared instance of the client (This segment of code would fit either into the dependency injection framework of the application if available or the JVM startup/shutdown)

LDClient client = new LDClient("sdk-key-123abc");

  1. Retrieve and use the flag values as below:
LDContext context = LDContext.builder("context-key-123abc")
  .name("Sandy")
  .build();

boolean flagValue = client.boolVariation("flag-key-123abc", context, false);

if (flagValue) {
  // Application code to show the feature
}
else {
  // The code to run if the feature is off
}
  1. And cleanup on application termination
client.close()

Meaning of shutting down the application will vary based on the injection points that are available within the JVM where the AM runs. So I am looking for advise on where we can plug this in, into the AM and have it available for use preferably within a scripted decision node across multiple journeys within a realm.

#4

Hi Nathan,

I can see two options.

  • Use Guice injection. This would be limited to custom Java nodes. I am not sure wether this method could be applied to OAuth2 custom plugins, for example. And that would not be available in Scripted Decision node, so you’ll have to place the custom java node in all tree, and set shared state with the feature flags. Very intrusive. Also, with this methodology, ensure feature flags are read once and cached: it is not recommended to perform external calls in authentication and authorisation flows, for obvious performance reasons.
  • Set the featured flags in the AM environment at deployment time as part of the CI/CD flow. Then this environment is accessible for any AM script.

I believe the latter approach is consistent with the reasonable usage of feature flags in release management, e.g for canary releases, early access programs or beta releases.

Regards
Patrick

1 Like
#5

Thank you for the updates Patrick.

Feature flagging solution involves realtime updates of the feature flags by our business using the feature flag portal. Hence the deployment time option might not fit our usecase.

As you mentioned the guice injection is specific to custom java nodes this might not apply as we went the direction of scripted nodes for our implementation.

We were looking at building a singleton java class that is loaded as a servlet filter and destroyed during tomcat shutdown as a JVM level option. Which could be whitelisted to be consumed from the scripted decision node.

Is this an alternative that we can pursue for this usecase?

Thank you
Ram

#6

Hi @rjeghanathan,

Are you going to apply this in production? This will definitely affects the overall platform performances, and defeats also the purpose of immutable configuration practices. If this is for a development or test environment, in that case that would make sense.
So with regard to using a servlet that initialises the library on startup, that should be do-able. Then the singleton should be available to any script or custom plugins, provided the class is whitelisted. I can’t tell you wether this works for sure, as I have never seen customers deploying in such a way, nor have I tried this; most are using the more traditional CI/CD way of pushing features from development to production in a consistent way. Also, it might be worth checking with ForgeRock support about the supportability of such a customisation,

Regards
Patrick

2 Likes