НК
Или хорошо нормализованная база даёт малый оверфетчинг полей и заморачиваться вообще не стоит?)
Size: a a a
2019 November 02
a
Я думаю как и везде зависит от специфики проекта
a
Нет смысла оверинженерить для проекта где не будет проблем с производительностью
a
Плюс в более менее сложных проектах источников данных несколько обычно
P@
Скажите а какие есть решения, если у меня есть роли в системе и часть функционала только для админов. На уровне резолвера проверять авторизацию - понятно. А как можно сделать чтобы схему иметь отдельно для юзера и отдельно - более богатую для админа?
Однозначно два разных эндпоинта. Легче логи смотреть, легче разбивать приложение на два сервиса , легче авторизацию крутить.
a
Плюс в более менее сложных проектах источников данных несколько обычно
И не всегда это реляционная бд
M
Однозначно два разных эндпоинта. Легче логи смотреть, легче разбивать приложение на два сервиса , легче авторизацию крутить.
Значит будет 2 отдельных схемы? По сути два отдельных приложения
НК
Нет смысла оверинженерить для проекта где не будет проблем с производительностью
Спасибо!
P@
Значит будет 2 отдельных схемы? По сути два отдельных приложения
Можно к одному экспрессу прикрутить два разных урла и на каждом своя схема. Можно два приложения запустить.
У нас одна кодовая база а приложений запускается два, в зависимости от ENV переменной стартуем публичный или админский апи.
У нас одна кодовая база а приложений запускается два, в зависимости от ENV переменной стартуем публичный или админский апи.
M
Можно к одному экспрессу прикрутить два разных урла и на каждом своя схема. Можно два приложения запустить.
У нас одна кодовая база а приложений запускается два, в зависимости от ENV переменной стартуем публичный или админский апи.
У нас одна кодовая база а приложений запускается два, в зависимости от ENV переменной стартуем публичный или админский апи.
Понятно спасибо. Хорошо если посмотреть что у нас не только 2 празных роли а гибкие разные права доступа. то есть есть юзер которому можно то то и то, есть другой которому можно другое, но они примерно одного уровня... То есть в общем виде как-то эта задача решается?
DT
Можно на уровне приложения — бывают проверки на владение данными (редактировать пост может его автор)
M
Можно на уровне приложения — бывают проверки на владение данными (редактировать пост может его автор)
Да! написал и тоже об этом подумал. всё вроде пазл складывается
P@
Понятно спасибо. Хорошо если посмотреть что у нас не только 2 празных роли а гибкие разные права доступа. то есть есть юзер которому можно то то и то, есть другой которому можно другое, но они примерно одного уровня... То есть в общем виде как-то эта задача решается?
Тогда одна схема и в каждом резолвере проверка прав. Либо руками, либо если схема генерируется, то какими нибудь мидлварами или декораторами
FM
Понятно спасибо. Хорошо если посмотреть что у нас не только 2 празных роли а гибкие разные права доступа. то есть есть юзер которому можно то то и то, есть другой которому можно другое, но они примерно одного уровня... То есть в общем виде как-то эта задача решается?
Решается, в апполо через проверку контекста и например токен доступа
FM
Graphql решает через auth директиву
NP
подскажите пожалуйста как должен примерно выглядеть резолвер?
резолвер thread должен принимать board родителя и num из ключа выше
как такое реализовать?
резолвер thread должен принимать board родителя и num из ключа выше
как такое реализовать?
AL
Странная какая-то кверя максимально.
e
подскажите пожалуйста как должен примерно выглядеть резолвер?
резолвер thread должен принимать board родителя и num из ключа выше
как такое реализовать?
резолвер thread должен принимать board родителя и num из ключа выше
как такое реализовать?
а как в тредах посты появились?
e
треды == посты
NP
это не мое апи )