Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Offer a common, slim LDClientInterface #23

Open
kevincianfarini opened this issue Feb 11, 2024 · 5 comments
Open

Offer a common, slim LDClientInterface #23

kevincianfarini opened this issue Feb 11, 2024 · 5 comments

Comments

@kevincianfarini
Copy link

kevincianfarini commented Feb 11, 2024

I am working on open sourcing a Kotlin Multiplatform feature flagging abstraction library which my team at work has used happily for 2+ years. Until now, it's had a tight coupling to Android and iOS clients, but in the library release I'm hoping to generalize my JVM implementation across both server and client.

The java-sdk-common library is the exact thing I need, but it does not offer a LDClientInterface for which I can write common code against. Instead, both the Android and the java server clients choose to declare these API surfaces in their respective package namespaces. They differ slightly, but offer some common API which could be shared across SDK clients.

My proposal is to offer an interface named CommonLDClientInterface with the following functionality.

package com.launchdarkly.sdk;

interface CommonLDClientInterface extends Closeable {

    boolean boolVariation(String flagKey, boolean defaultValue);
    EvaluationDetail<Boolean> boolVariationDetail(String flagKey, boolean defaultValue);

    int intVariation(String flagKey, int defaultValue);
    EvaluationDetail<Integer> intVariationDetail(String flagKey, int defaultValue);

    double doubleVariation(String flagKey, double defaultValue);
    EvaluationDetail<Double> doubleVariationDetail(String flagKey, double defaultValue);

    String stringVariation(String flagKey, String defaultValue);
    EvaluationDetail<String> stringVariationDetail(String flagKey, String defaultValue);

    LDValue jsonValueVariation(String flagKey, LDValue defaultValue);
    EvaluationDetail<LDValue> jsonValueVariationDetail(String flagKey, LDValue defaultValue);

    void registerFeatureFlagListener(String flagKey, FeatureFlagChangeListener listener);
    void unregisterFeatureFlagListener(String flagKey, FeatureFlagChangeListener listener);
}

And then have each respective platform's interface extend the common one:

Android:

package com.launchdarkly.sdk.android;

import com.launchdarkly.sdk.CommonLDClientInterface;

public interface LDClientInterface extends CommonLDClientInterface { /* omitted */ }

Server:

package com.launchdarkly.sdk.server.interfaces;

import com.launchdarkly.sdk.CommonLDClientInterface;

public interface LDClientInterface extends CommonLDClientInterface { /* omitted */ }

My motivation for this feature is that the Kotlin Multiplatform Android integration is in a slight amount of flux. Ownership of the android multiplatform target is being transferred from the Kotlin team at Jetbrain to the Android team at Google. The benefit of this request is not just code de-duplication between JVM and Android, but also API stability in my library since I am not required to use the Android target.

Currently, it doesn't look like the JVM server client API supports registering feature change change listeners like the Android client does, but perhaps this is possible. It seems like a hook into InMemoryDataStore#upsert could be written to notify listeners similar to how the Android client works. Aside from my use case, this could be useful for persistent server endpoints, like websockets and HTTP server sent events.

I want to reiterate though that this request is limited to simply offering an interface with the above functionality.

@tanderson-ld
Copy link
Contributor

Hi @kevincianfarini, thank you for reaching out. We plan to migrate our Java based SDKs into a monorepo in the future and that is likely when we would consider doing this work. In the mean time we will discuss this on team and let you know the outcome.

@kevincianfarini
Copy link
Author

Thank you for your consideration! Eager to hear what your team thinks.

Copy link
Contributor

This issue is stale because it has been open for 90 days without activity. Remove the stale label or comment, or this will be closed in 14 days.

@github-actions github-actions bot added the Stale label Aug 27, 2024
@kevincianfarini
Copy link
Author

I'd still love this issue worked on.

@github-actions github-actions bot removed the Stale label Aug 28, 2024
@octoeddy
Copy link

octoeddy commented Oct 2, 2024

I would also really appreciate this , we use Monarch with Compose multiplatform, and this makes it difficult to support our JVM target

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

No branches or pull requests

3 participants