search

launchdarkly / android-client-sdk

LaunchDarkly Client-side SDK for Android
Other
45 stars 23 forks source link

Allow to specify a set of flags used by a client #166

Open denis-bezrukov opened 2 years ago

denis-bezrukov commented 2 years ago

Is your feature request related to a problem? Please describe. We have a ~450 active flags, while client only uses ~90 at a time. That means all 450 are evaluated / stored on the client (in our case it is already 150KB shared preference) which is potentially slows down initialization / flags update.

We could archive unused flags, but there are issues with that:

  1. Since it's mobile, it's almost impossible to achieve 100% rollout. We committed to support old clients up to 1-1.5year. So we should wait for 1.5 years after removing a flag from the code.
  2. There are flags that never used by our client (e.g. if a flag only used by our backend).

Describe the solution you'd like Allow to provide a list of flags client will use. LD will request and store only these flags.

gwhelanLD commented 2 years ago

Hi @denis-bezrukov,

To clarify your request, it sounds like you would like to be able to set a configuration option for the SDK itself that it would send to the service when requesting flag data that limits the flags received to a certain subset. Is that correct?

For (2) above, our documentation on Client-side SDK availability may be helpful. You can already configure from the dashboard which flags are received by the mobile SDKs.

Thanks, @gwhelanLD

denis-bezrukov commented 2 years ago

Hi @gwhelanLD, thanks for the response,

To clarify your request, it sounds like you would like to be able to set a configuration option for the SDK itself that it would send to the service when requesting flag data that limits the flags received to a certain subset. Is that correct?

Yep, this is correct

For (2) above, our documentation on Client-side SDK availability may be helpful. You can already configure from the dashboard which flags are received by the mobile SDKs.

I believe backend team is also using mobile key rather than client id, but even if they migrate to client id it will not help, because beside backend we have a second mobile platform (which has their own subset of FF along with shared ones). And we won't be able to separate flags between these two mobile clients via this flag

gpeal commented 2 years ago

There is also the issue of devices running old versions of the app. If we turn off the client side availability, old devices will revert to their default value which is effectively off and this could lead to unexpected or broken behavior on older apps.