Add actors API endpoint

[kathf]

Add an endpoint to Flipper::API to check if a feature is enabled for a specific actor.

I'm using Flipper and Flipper::UI in a production web app which is also the backend server for mobile apps. These changes would allow our mobile apps to get data just for the signed-in member, without having to parse all the data from the feature endpoint client-side.

Usage:

get "/feature/my_feature/actor", {'flipper_id' => 'User123'}

[kathf]

I'm struggling to fix up the spec failures, but if you're interested in the feature let me know and I will persevere. Thanks

[jnunemaker]

@kathf thank you so much for contributing!

I remember having a conversation with @AlexWheeler when he first created the API about something like this but I can't find it for the life of me.

Thus far we've went with an API that is smart client, simple server. The server doesn't have logic about enabled-ness. It is only for storage. Adding this might feel like a small change, but it is a big change in approach.

I like the idea of having an easy route you can hit for one actor, especially for read only clients like mobile and clients in other programming languages.

I wonder if the route should be more the inverse of /features, but for a single actor. The route could be /actors/<actor_id> and support a keys param for limiting which features to check (ala /features keys param). This would allow clients to batch read several features at once (say for running every N seconds to lower read throughput or for more detailed caching).

@AlexWheeler @kathf (or anyone else) any thoughts either way on that?

[kathf]

@jnunemaker glad to hear you like the idea :)

Yeah I think you're right about the /actors/<actor_id> route with key param for limiting features - it accommodates more use cases and looks neater.

[kathf]

Branch updated accordingly.

[AlexWheeler]

Hey @kathf this is awesome thanks for the PR! As @jnunemaker mentioned definitely a different approach than the API has taken, but I agree with both of you that this will be really useful for the cases mentioned. I also like the idea of an actors/<flipper_id> route with the ability to batch read features. Going to give this a look today

[jnunemaker]

Hey! This is looking great! So close.

If you have more time to take it over the line that would be great, if not, I'd be happy to help. I hate to add burden to contributors like yourself but I have to balance that with ensuring that what is merged is what I'm ready to maintain forever. 😄

I'm only commenting because I'm curious what your thoughts and @AlexWheeler's are. Requesting changes felt to intense for questions. :)

[jnunemaker]

What are your thoughts on making this 'features' => {'my_feature_1' => {'enabled' => true}}. The Hash lookup would make it easier to get at an individual feature. Keeping 'enabled' => true as a hash means we can always add more keys/values if we need. Also, 'features' being a hash means we could always add pagination information there if we ever paginate features due to the sheer number people could have.

[kathf]

Yep, good call 👍

[jnunemaker]

Flipper's default behavior is to not worry about features that don't exist. They are just not enabled. I'm inclined to say this should do the same. Any features passed that don't exist should still be present in the response, but just be enabled => false. That allows us to remove the feature existence check from the action which reduces network calls (like requesting the set of known features) as well. Thoughts?

[kathf]

Yep, I agree.

[jnunemaker]

Does this method help us at all? I wonder if we could just inline it since it is only used once and the contents of it are one very simple method call.

[kathf]

Hi @jnunemaker I've made all those changes.

I agree with the all of your comments and also I get it about ensuring maintainability for you and the other maintainers. Thanks for writing a great gem!

[jnunemaker]

@kathf it has been a pleasure working with you. Thanks for the contribution!