-
Notifications
You must be signed in to change notification settings - Fork 6
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
Comments
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. |
Thank you for your consideration! Eager to hear what your team thinks. |
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. |
I'd still love this issue worked on. |
I would also really appreciate this , we use Monarch with Compose multiplatform, and this makes it difficult to support our JVM target |
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 aLDClientInterface
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.And then have each respective platform's interface extend the common one:
Android:
Server:
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.
The text was updated successfully, but these errors were encountered: