`expose_authorization_rules` Changes

[lifeiscontent]

Hey @palkan hope you're doing well!

This week we just started to implement feature gates in our GraphQL API.

I was wondering if you've done this kind of thing, and if you think ActionPolicy was a good place for this kind of thing.

One thought that I had was if I added feature gates to a policy I could share it across the app vs just in GraphQL.

another question that I had was around the expose_authorization_rules API, do you have any real world examples as to why you would want to show anything other than a boolean here? I find myself only ever reaching for the .value in the AuthorizationResult.

I was curious if you'd have any realistic use cases for the rest of the information like reasons that are exposed in the AuthorizationResult.

If not, I'd propose a change to something like:

 expose_authorization_rules :edit_profile, 
                             :create_profile, 
                             boolean: true

to return a boolean instead of an AuthorizationResult.

what do you think?

[palkan]

why you would want to show anything other than a boolean here?

This gem was extracted from the real-life application, and expose_authorization_rules was one of the key features. I shared some examples in this deck: https://speakerdeck.com/palkan/rubyrussia-2019-welcome-or-access-denied?slide=104

We used reasons heavily to differentiate "access denied" messages and sometimes UX elements (e.g., adding a button "Request access" when particular reasons are present in the AuthorizationResult).

return a boolean instead of an AuthorizationResult.

We have canSmth { value } for that. I don't think it makes sense to simplify things when using GraphQL, it could be easily done client-side.

[lifeiscontent]

@palkan that makes a lot of sense, thanks for sharing.

I'm curious, have you done any a/b test in GraphQL?

e.g. new_feature_enabled_for?(user)

I was thinking about exposing this kind of thing in the ActionPolicy, but I'm not sure if this is the right abstraction.

Would love to hear your feedback if you've done something like this.

[palkan]

have you done any a/b test in GraphQL?

Yeah, I had. I'd suggest using a dedicated abstraction for that (usually, we use something like context[:features]). You can add custom field extensions similar to what we have for authorize: true to support smth like: field :new_field, feature: :new_feature

[lifeiscontent]

@palkan thanks for the input!