strawberry
strawberry copied to clipboard
strawberry-graphql
Add runtime features to schema directives
Currently directives only act as "tags", ideally they would support custom functionality. For example, we'd like to check that a specific request header is set when calling mutations with a given directive.
I've changed the title to be focused on schema directives :)
Client directives are already used at runtime ☺️
Can you all add some use cases for this?
Great one would be Apollo's APQ (https://www.apollographql.com/docs/apollo-server/performance/apq/). Build middleware for it 👯
@basvandriel how would that work? from what I see in those docs you add some directives and then you add a plugin. The directives don't do anything alone, right?
@patrick91 As far as I understand, query results are not cached, just the query string to improve improvements. Also has it's security reasons imo. It sends the queries in a sha256 hash. See the diagram in the link
The main use case for me is applying permissions, but have those permissions be visible to the client so that the client knows what headers to send or under what scopes they can access such mutations, without having to look at backend code.
One implementation option or additional idea could be to extend BasePermission to be linked to a directive.
Hey guys,
Joining the conversation here to add my thoughts.
There are some interesting use cases for schema directives that have runtime functionality. For example, I expanded the current schema directive in strawberry-django-plus (https://github.com/blb-ventures/strawberry-django-plus/blob/master/strawberry_django_plus/directives.py) to be able to add runtime permission checking: https://github.com/blb-ventures/strawberry-django-plus/blob/master/strawberry_django_plus/permissions.py
One interesting feature of this approach is that they get printed to the schema, so someone consuming it can parse it to retrieve some extra info. E.g. the frontend guys that work with me parses our schema and checks for the permissions there. Knowing the current user's permissions they can add @include/@skip directives to avoid querying a field that they know they will not have permission for (and even if they did, the runtime functionality would not allow it).
