KN
Но то что осталось - тоже тебе понравится
Size: a a a
2019 March 13
KN
Я вижу прям братьев по... кхм... взглядам
AU
Я думаю тебе понравится этот чел: https://www.youtube.com/channel/UC6zU98JOJa7gMpU6ZRjb9eg
сразу видно парень шарит явно и истоков держится
KN
ну вот, я даже подписан на него
KN
до его уровня, конечно, далеко, но стараюсь
RD
Я думаю тебе понравится этот чел: https://www.youtube.com/channel/UC6zU98JOJa7gMpU6ZRjb9eg
KN
это, конечно, могло бы стать аргументом... Но только тогда, когда какой-то путь уже не пройден
IK
как можно реализовать пермишены для graphql апи?
желательно что бы была возможность ограничений на уровне филда.
нагуглил вариант с использованием диркетив.
https://blog.apollographql.com/auth-in-graphql-part-2-c6441bcc4302
желательно что бы была возможность ограничений на уровне филда.
нагуглил вариант с использованием диркетив.
https://blog.apollographql.com/auth-in-graphql-part-2-c6441bcc4302
NT
graphql shield)
δM
Всем привет!
У меня возник вопрос по структурированию данных.
А точнее композиция VS наследование.
Допустим у меня есть типы, представляющие облачную инфраструктуру.
И есть тип Datastore представляющий некий конкретный инстанс базы данных.
Проблема появляется, когда в этот тип хочется добавить поля, специфичные для конкретного типа БД (например cassandra или mysql).
И тут два варианта:
1) использовать интерфейс, который определяет общие поля для всех. И конкретные типы, которые имплементируют этот интерфейс + дополнительные поля.
2) использовать один тип, но добавить к нему поле “data” которое будет Union и содержать специфичные детали
Ситуация осложняется тем, что у меня целая иерархия подобных объектов и для каждого типа нужны специфичные вариации.
Кто нибудь дизайнил подобное?
У меня возник вопрос по структурированию данных.
А точнее композиция VS наследование.
Допустим у меня есть типы, представляющие облачную инфраструктуру.
И есть тип Datastore представляющий некий конкретный инстанс базы данных.
Проблема появляется, когда в этот тип хочется добавить поля, специфичные для конкретного типа БД (например cassandra или mysql).
И тут два варианта:
1) использовать интерфейс, который определяет общие поля для всех. И конкретные типы, которые имплементируют этот интерфейс + дополнительные поля.
2) использовать один тип, но добавить к нему поле “data” которое будет Union и содержать специфичные детали
Ситуация осложняется тем, что у меня целая иерархия подобных объектов и для каждого типа нужны специфичные вариации.
Кто нибудь дизайнил подобное?
a
в GraphQL вы описываете схему данных с точки зрения предметной области, а не способа её хранения
a
мне кажется, надо придерживаться такого подхода
a
а хранение должно быть скрыто внутри резолверов
δM
с хранением там всё ещё хуже)
меня как раз интересует система типов и её косумер
меня как раз интересует система типов и её косумер
XZ
P@
@RIP21 кросавчег, запилил workaround для Optional Chaining’а в Тайпскрипте 👍😱🚀
https://twitter.com/nodkz/status/1105843389889761286
https://twitter.com/nodkz/status/1105843389889761286
P@
Полезна будет для фронтендеров.
AU
Откуда здесь фронтендеры