search

launchdarkly / dotnet-sdk-common

Code shared between dotnet-server-sdk and dotnet-client-sdk
Other
3 stars 10 forks source link

Allow for custom caching key #47

Open DanielRBaird opened 4 years ago

DanielRBaird commented 4 years ago

See: https://github.com/DanielRBaird/dotnet-sdk-common/pull/1

Adding a caching key to the user would allow for caches to support keeping separate data based on whatever differences the implementer cares about. Example:

A user has multiple projects that they are a part of. Projects are identified by a custom property. We want to cache user flags for different project values. { "key":"user1", "project":"project1" } then also keep { "key":"user1", "project":"project2" }

Currently this is unsupported by the library, and switching the user project value would require another successful call to LD before the flag would be updated.

This change would allow current integrations to continue to operate exactly as they do now by defaulting to using the user key for caching, but would also allow Launch Darkly users to cache more data without writing all of their own caching.

eli-darkly commented 4 years ago

@DanielRBaird I believe the support team has been talking with you about the requirements that this issue is related to—am I right? If so, we should continue the discussion on that channel instead of here, since changing the SDK in this way is just one possible way to address your use case.

DanielRBaird commented 4 years ago

Yep. Happy to continue that conversation with support. Based on the way that the mobile clients work, this would be the easiest way forward for us and could provide additional flexibility for all other users as well. Just thought I would throw this out there as a solution.

eli-darkly commented 4 years ago

The main reason we would probably not want to use this approach is that it's really contrary to the LaunchDarkly model in general to reuse the same user key for two different sets of properties that you explicitly want to behave differently. Other things besides mobile caching are not going to work properly if you do this: for instance, analytics events (and anything based on analytics events, like your user dashboard) are likely to treat these as the same user, since the rest of the system needs to do some basic caching for efficiency and does not have this new concept you've added of a "cache key" distinct from the user key. It sounds like there is a slight mismatch between what your application considers to be a "user" and what a user means in the LD model. I've brought this up in my own conversations with support about your use case, but I wanted to also mention it here for the benefit of anyone else who's looking at this issue.

DanielRBaird commented 4 years ago

Well, for our case we actually would want analytics to treat these as the same user because we have one user logged in. We are just tweaking a piece of information about what the user is currently accessing, and based on the project that they are looking at we want to potentially serve different flags.

This is the way that we would generally tend to use launch darkly if our app were always expected to be online, but because only one set of flags is cached for a given user key, we cannot cache values based on variations in the users custom attributes.

Based on my knowledge of this, the only other real alternative is to create a user key based on the variations on data. ("key"="user1+project1" for example) Which would certainly be much more destructive to having meaningful analytics based on the LD user key.

eli-darkly commented 4 years ago

Well, this sounds like a larger issue that should be pursued in the existing discussion elsewhere, but when I say "contrary to the LD model" I mean that many aspects of LaunchDarkly are designed on the assumption that there is a consistent set of user properties corresponding to each user key. In general, if you looked at your analytics and the same user key was getting different flag values at different times, and the flag configuration had not changed, that would be considered a sign that something was wrong with the service. And unless you're using full data export, it does not even include the full set of user properties in analytics events most of the time— it deduplicates them based on user key, so you would not be able to tell which set of properties was producing which flag value based on the event data. And if you look at your user dashboard you'll see that it is only recording one set of properties for any given user; if you send different properties at different times, what you'll see will be arbitrary based on timing.

Again, I don't want to get into an in-depth discussion of your application design in Github comments, but your use case is unusual and it's not how we recommend that the SDK be used.