кто где хранит локальный стейт в apoolo-client? Мне история с кэшем вообще чота не нравится( Склоняюсь к реактовскому контексту

prisma/prisma 1.26.4 → 1.26.5 🎉

Насколько я понял по ишью в их репо, такой фичи у них нет

Можно сделать middleware, которое, например, закроет схему:

class TopSecretMiddleware(object):
    def resolve(self, next, root, info, **kwargs):
        if info.field_name == '__schema':
            return None
        return next(root, info, **args)

class TopSecretMiddleware(object):
    def resolve(self, next, root, info, **kwargs):
        if info.field_name == '__schema':
            return None
        return next(root, info, **args)

спасибо. я уже привык по поводу сколько-нибудь кастомного поведения с графеном делать самопальные штуки)

Да, библиотека очень интересная)

а документация какая...

И баги фиксят оперативно!

Заинтересовал вопрос, что выбрать custom scalars vs. custom schema directives (или middleware) для валидации полей?

Например, нужно чтобы значение поля было в формате email:

scalar EmailAddress

type User {
  mail: EmailAddress
}

vs

type User {
  mail: String @constraint(format: email)
}

vs

middleware c проверкой на формат.

Есть пакет https://github.com/okgrow/graphql-scalars с готовыми скалярными типами.

Есть 2 пакета https://github.com/confuser/graphql-constraint-directive и https://github.com/vsimko/node-graphql-constraint-lambda с директивой @constraint.

Интересует ограничения и потенциальная гибкость (плюсы и минусы) каждого подхода.

На первый взгляд кажется, что директива гибче, так как директиву можно потенциально применить только к инпуту конкретной мутации, а в другой мутации не применять к этому полю. Если же в самом типе это поле имеет кастомный тип, то во всех мутациях будет это ограничение.

Вопрос номер 2:

В проекте нужно реализовать пользователям ролевую систему. Обычно везде делают так:

enum Role {
  USER
  MODERATOR
  ADMIN
}

type User {
  roles: [Role]
}

Но если потом вдруг понадобится расширить список ролей потребуется вносить изменения в SDL (в этот enum).

Вариант с type вместо enum кажется гибче:

type Role {
  id: ID!
  name: String
}

type User {
  roles: [Role]
}

Ну и сделать мутации createRole, updateRole, deleteRole, которые могут дёргать только юзеры с ролью администратора.

Чем вариант с enum может быть выигрышнее? Упускаю ли я что-то?

enum Role {
  USER
  MODERATOR
  ADMIN
}

type User {
  roles: [Role]
}

type Role {
  id: ID!
  name: String
}

type User {
  roles: [Role]
}

Мне кажется без разницы, кому как удобнее, кто-то не против динамического изменения ролей, кто-то не любит ничего запоминать (как я) и ему лучше что б все роли были указаны в enum

То есть автокомплит при наборе запроса?

ну, и автокомлит тоже, но я про код имел ввиду, что бы когда пишешь была уверенность какие роли есть, как они пишутся. Ну и фронту не придется ничего рассказывать, он всё из схемы увидит

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

так что дело вкуса мне кажется

Так ведь можно через query достать их на фронте:

query {
  roles {
    id
    name
  }
}

ну можно и отдельным запросом :)

А по поводу первого вопроса что скажешь?

Статья по которой я буду выступать в эту субботу в Нижнем Новгороде
https://github.com/nodkz/conf-talks/tree/master/articles/graphql/schema-build-ways#%D0%B2-%D0%B8%D1%82%D0%BE%D0%B3%D0%B5-%D1%87%D1%82%D0%BE-%D0%B8%D0%BC%D0%B5%D0%B5%D0%BC-%D0%BF%D0%BE-%D0%BF%D0%BE%D0%B4%D1%85%D0%BE%D0%B4%D0%B0%D0%BC

сравниваю подходы в построении схем

тут я хз честно говоря