Skip to content

Conversation

ermanc
Copy link

@ermanc ermanc commented Apr 13, 2016

In our current use case, we're using get_user_settings to expose all flags for a given user at once. For the most part, that works great.

However, toggle? has the nice side-effect of auto-registering the users we call it with, which we don't get to have with this method. Calling identify for each user we want to get all flags of (whether at the time of the call or on a schedule) seems like a weird divergence from how toggle? Just Works ™️

I didn't want to call add_event directly, as identify does exactly the thing that we're looking for here, so I just delegated that.

This would be super helpful. Let me know if I'm missing something.

@kbarrette
Copy link
Contributor

@jkodumal looks like you are fairly active in this repo - what do you think of this approach?

@jkodumal
Copy link
Contributor

We've been debating the best approach here. The issue is that we want get_user_settings to send back analytics events for the flags that were actually accessed. Identify won't register analytics events, it will only add the user to our dashboard.

Our current experience is that most of our customers are passing the result of get_user_settings to their front-end, to bootstrap feature flags on the client side. Is that what you're doing as well? If so, we are working on an approach that would make that use case more seamless.

@kbarrette
Copy link
Contributor

@jkodumal yup! Basically we have a few consumers of feature flags where it's most convenient to get_user_settings on the back end and pass that through. For this use case, it'd be nice if get_user_settings identified the user (similar to the way toggle? does).

For now, we're working around this by calling identify before get_user_settings

@ermanc
Copy link
Author

ermanc commented Apr 14, 2016

@jkodumal Thank you for checking in! I can understand where you guys are coming from, missing analytics data is not ideal. And it seems like there are quite a few other users who take a similar approach like we do as it is quite nice to be able to expose feature flags from the endpoint without having the consumer contact LD directly. Especially when some of those consumers have limited communication capabilities/channels.

Don't wanna overstep here but any chance you guys can move the analytics event to the actual comparison method evaluate? Since the only callers of that method are toggle? and get_user_settings, I think the overall effect would be similar.

In any case, I'm looking forward to what you have in the works for this use case. Would love to get this merged but like @kbarrette pointed out, we have our workaround to handle this for now.

eli-darkly added a commit that referenced this pull request May 10, 2018
include variation index in events and bump schema version to 3
@eli-darkly eli-darkly closed this Oct 24, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants