фильтрации аргументов для мутаций, т.к. переиспользовать отдельные "правила" не сможешь, ведь редко бывает, что инпуты у разных мутаций одинаковые. Имхо, эту логику лучше держать прямо в резолвере, поближе к коду. Насколько часто возникает проблема фильтрации полей? Почему бы не сделать lodash.omit прямо в резолвере при условии, что пользователь не админ?
Middleware и так максимально близко к резолверу. Идея как раз в том, чтобы не трогать резолвер. См. подробнее: https://www.prisma.io/blog/graphql-middleware-zie3iphithxy Я бы не сказал, что задача авторизации на конкретных аргументах и инпутах возникает очень часто. В большинстве случаев хватает ограничить по роли всю мутацию целиком. Но если нужен более гибкий, точечный granular-подход, то "красивого" решения не было. Насчёт переиспользуемости инпутов. Например, Prisma когда генерирует квери и мутации из модели данных, выделяет все аргументы в отдельные инпут-типы. Имена этих инпут-типов уникальны для каждой мутации. И это best practice. Но Prisma позволяет делать так называемые nested mutations. И внутри инпута возникает вложенные инпуты со словами create, update, upsert, delete, connect, disconnect. И вот эти вложенные инпуты одни и те же для одной и той же сущности. То есть присоединение (connect) поста (Post) не зависит от того, к чему я хочу приконнектить этот пост, к юзеру (User), блогу (Blog) или любой другой сущности. Но если я хочу, чтобы я мог коннектить пост к юзеру, а к блогу не мог, то я пишу правило на запрет connect внутри аргумента блога. При этом на юзере это ограничение никак не скажется. При этом я могу запретить connect поста к блогу только при обновлении блога (updateBlog), но не при его создании (createBlog). Всё очень гибко.
Обсуждают сегодня