Здравствуйте, Sinclair, Вы писали:

S>Вы фильтром называете проекцию или что-то ещё?

да

КЛ>>ну смотри, у тебя два юзкейса — полный ресурс или урезанный.
S>Строго говоря, у нас может быть и больше юзкейзов.

вам и говорят, когда много, тогда у вас проблемы.

КЛ>>даже если ты будешь разруливать их через отдельные ресурсы где-то будет ветвление на создание (фильтрацию, сборку, как угодно) одного и другого.
S>Если я это делаю явным образом, то у меня это ветвление покрывается системой типов, и его статически контролирует компилятор ещё до того, как запустятся тесты.

система типов это только про поля, а что со строками?
это не гибко

КЛ>>я до сих пор не понимаю как добавление ресурсов принципиально что-то меняет в твоей модели и что это у меня за такая модель?
S>У вас модель, в которой заранее неизвестно, какая структура ресурса будет получена при обращении по тому или иному ендпоинту. Она типа "динамически" определяется где-то внутри кода непрозрачными правилами.

sql уже стал непрозрачными правилами. "у вас данные отдаются динамически по непрозрачным правилам". дело не сколько в структуре, а вообще в данных.
еше раз — пермисии это такой же фильтр данных как и остальные. разрулить их системой типов хорошо не получится.

КЛ>>а кто такое предлагает? я такое не предлагаю. и, кстати, популярный graphql именно это и делает, насколько я понимаю и я это осуждаю.
S>Нет, graphQL делает не это.

а что он делает?

КЛ>>не понимаю к чему ты. мы лишь про то, что по токену на беке получаем пермиссии и в зависимости он них отдаем респонс.
S>Как мы это будем тестировать?

а как вы тестируете все остальное, что отдает данные на основании пользовательского контекста?

КЛ>>graphql! и да, это бред, но это не то, что я предлагаю
S>В graphQL принято несколько неудачных решений, но не потому, что он "выставляет наружу БД".

да, но выставляет наружу псевдо-бд

Здравствуйте, Sinclair, Вы писали:

S>Вы фильтром называете проекцию или что-то ещё?

да

КЛ>>ну смотри, у тебя два юзкейса — полный ресурс или урезанный.
S>Строго говоря, у нас может быть и больше юзкейзов.

вам и говорят, когда много, тогда у вас проблемы.

КЛ>>даже если ты будешь разруливать их через отдельные ресурсы где-то будет ветвление на создание (фильтрацию, сборку, как угодно) одного и другого.
S>Если я это делаю явным образом, то у меня это ветвление покрывается системой типов, и его статически контролирует компилятор ещё до того, как запустятся тесты.

система типов это только про поля, а что со строками?
это не гибко

КЛ>>я до сих пор не понимаю как добавление ресурсов принципиально что-то меняет в твоей модели и что это у меня за такая модель?
S>У вас модель, в которой заранее неизвестно, какая структура ресурса будет получена при обращении по тому или иному ендпоинту. Она типа "динамически" определяется где-то внутри кода непрозрачными правилами.

sql уже стал непрозрачными правилами. "у вас данные отдаются динамически по непрозрачным правилам". дело не сколько в структуре, а вообще в данных.
еше раз — пермисии это такой же фильтр данных как и остальные. разрулить их системой типов хорошо не получится.

пример — у юзера есть 5 основных воркфлоу, в один из которых входит создание внутренних отчетов из таблицы rows, в другой создание анонимизтированных отчетов для регулятора.
внутренний отчет показывает конфиденциальные данные, для регулятора отрезает их.
опиши security-модель для такого? сколько ролей? как все работает?


КЛ>>а кто такое предлагает? я такое не предлагаю. и, кстати, популярный graphql именно это и делает, насколько я понимаю и я это осуждаю.
S>Нет, graphQL делает не это.

а что он делает?

КЛ>>не понимаю к чему ты. мы лишь про то, что по токену на беке получаем пермиссии и в зависимости он них отдаем респонс.
S>Как мы это будем тестировать?

а как вы тестируете все остальное, что отдает данные на основании пользовательского контекста?

КЛ>>graphql! и да, это бред, но это не то, что я предлагаю
S>В graphQL принято несколько неудачных решений, но не потому, что он "выставляет наружу БД".

да, но выставляет наружу псевдо-бд