prisma/prisma 1.31.0 → 1.31.1 🎉

Всем добрый вечер, на днях мы с @FluorescentHallucinogen задались вопросом, как фильтровать input параметры по простому, также как это можно делать с резолверами через graphql-shield, но для мутаций, для input полей. В итоге была написана библиотека, позволяющая по заданной схеме фильтровать входящие параметры (args в коде) согласно заданной схеме, идея в следующем: описывается объект, структурно такой же как и input параметры но в котором содержатся не сами параметры, а только boolean значение, сохранять (true) или исключить параметр из аргументов мутации, причём через поле '*':true/false можно указать правило по умолчанию для неуказанных в схеме полей, а так же всех полей уровнями глубже (если только на более глубоких уровнях не было установлено новое правило по умолчанию, которое отменяет верхлежащее). Сама фильтрация происходит в созданном rule для graphql-shield. Пример работы данной библиотеки можно посмотреть здесь.
Так вот, что думаете насчёт такого метода, может есть предложения как можно упростить данное решение? Или всё херня и нужно юзать что-то другое?

звучит не очень

есть какая-то либа, с помощью которой можно провалидировать args типа

@minLength(10)

,

@maxLength(100)

и всякие подобные помогайки ?

@minLength(10)

@maxLength(100)

graphql-shield -> input validation -> yup

@uxname спасибо, гляну

Мне кажется, что graphql-shield/middleware - не очень хорошее место для фильтрации аргументов для мутаций, т.к. переиспользовать отдельные "правила" не сможешь, ведь редко бывает, что инпуты у разных мутаций одинаковые. Имхо, эту логику лучше держать прямо в резолвере, поближе к коду. Насколько часто возникает проблема фильтрации полей? Почему бы не сделать lodash.omit прямо в резолвере при условии, что пользователь не админ?

Они это шаманят, чтоб потом директивы сделать. И вешать проверки через SDL.

думаю стоит держать подобную валидацию ниже слоя с веб фреймворком

Что имеется в виду?

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).

Всё очень гибко.

Middlewares хороши тогда, когда один раз написал и забыл, т.е. ты уверен, что определенная логика выполняется, например проверка авторизации, логгирование.
Обновление админских полей в бд - задача, на которую необходимо обращать пристальное внимание, чтобы обычный пользователь случайно не обновил то, что ему не положено. В случае с добавлением проверки(фильтрации) полей в резолвер, данный этап постоянно бросается в глаза, так что при добавлении новых полей ты не забуешь обновить правила фильтрации. Я не говорю, что это правильно с точки зрения организации кода, я считаю, что это более подходит конкретно для данной задачи.

Имхо, дело вкуса. Мне проще, когда я не в мешанине коде выискиваю правила авторизации, а они описаны отдельно без лишнего визуального шума.

По поводу разделения на админские и неадминские мутации - полностью согласен.

> Но Prisma позволяет делать так называемые nested mutations. И внутри инпута возникает вложенные инпуты со словами create, update, upsert, delete, connect, disconnect. И вот эти вложенные инпуты одни и те же для одной и той же сущности. То есть присоединение (connect) поста (Post) не зависит от того, к чему я хочу приконнектить этот пост, к юзеру (User), блогу (Blog) или любой другой сущности.

Вот тут я ошибся. Там почти везде разные имена инпутов:

input OrganizationMemberUpdateManyWithoutOrganizationInput {
  create: [OrganizationMemberCreateWithoutOrganizationInput!]
  connect: [OrganizationMemberWhereUniqueInput!]
  set: [OrganizationMemberWhereUniqueInput!]
  disconnect: [OrganizationMemberWhereUniqueInput!]
  delete: [OrganizationMemberWhereUniqueInput!]
  update: [OrganizationMemberUpdateWithWhereUniqueWithoutOrganizationInput!]
  updateMany: [OrganizationMemberUpdateManyWithWhereNestedInput!]
  deleteMany: [OrganizationMemberScalarWhereInput!]
  upsert: [OrganizationMemberUpsertWithWhereUniqueWithoutOrganizationInput!]
}

Хотя вот часть из них всё-таки совпадают:

connect: [OrganizationMemberWhereUniqueInput!]
set: [OrganizationMemberWhereUniqueInput!]
disconnect: [OrganizationMemberWhereUniqueInput!]
delete: [OrganizationMemberWhereUniqueInput!]

Всем привет. Использую React+Apollo, делаю запрос за данными на сервер, в network вижу что данные приходят корректные, но в компонент они приходят неправильные - Apollo достает их из кэша. если убираю из схемы поле id, то все норм (видимо он тянет из кэша по id), но мне нужно это поле. Где он хранит этот чертов кэш - непонятно, в другом браузере та же проблема. Пробовал fetchPolicy 'network-only' и 'no-cache' - не помогает. подскажите как избавиться от ненавистного кэша именно для данной query или может как удалить или обновить этот кэш?

решение в лоб: заюзай graphql-request для этого запроса

гляну, спасибо

тут два варианта, или fetchPolicy твоего запроса не позволяет обратится к актуальным данным (решение: сделай ее 'cache-and-network') или же данные приходят в компонент но пропсы не обновляют отображение (возможное решение: 'key' который будет менятся при изменении твоих данных)