Schema documentation and Client-side logic

[frankdugan3]

This looks really awesome, especially with the new features coming in 3.0!

I'm currently using schema directives to enforce permissions based on Apollo's docs. I've added two features that really benefit my app:

1. The directive appends the field description with a markdown-rich explanation of the permissions rules so you can see the requirements right in GraphiQL/Playground.
2. It generates (hackishly, and only in dev environment) TS definitions and objects that contain information about permissions rules so the client can proactively exclude fields or disable queries/mutations it predicts may be unauthorized.

So, I have a couple questions. I'm also happy to contribute to any of these features if they seem possible and interesting.

1. I'm not sure how the introspection query works under the hood, but would it be possible for this library to append information to the descriptions of fields based on permissions rules?
2. Any thoughts on how to expose the permissions rules to client-side logic? Obviously some require data from the query itself, but at least simple access rules, like isAuthenticated and isAdmin etc. could be derived.

[maticzav]

Hey, I thought I already replied to this, sorry for the delay. I love your idea! Unfortunately, we entirely rely on graphql-middleware. I think it would be possible to do some auto-generation which could turn out really cool, but I am not so sure about the description idea. It is possible, but I think we should find a bit more use cases to add such functionality to grpahql-middleware.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Victordmdb]

Hi, I'm curious if there's a simple way to determine if the user has permission for mutations from the client? Or would it require an introspection query?

[maticzav]

@Victordmdb I am not sure I understand your question. From what I know, neither of the two would give you that information. One way I can imagine obtaining such information would be by forwarding a role in user's session information. That, however, would have to be determined by the business logic of your application, not the schema.

[Victordmdb]

@maticzav I'm testing out CASL which fits well with graphql-shield to handle permissions at every level.

[veeramarni]

@Victordmdb Will you suggest to use CASL based on your testing?