Здравствуйте, Sinclair, Вы писали:
S>Вы фильтром называете проекцию или что-то ещё?
да
КЛ>>ну смотри, у тебя два юзкейса — полный ресурс или урезанный. S>Строго говоря, у нас может быть и больше юзкейзов.
вам и говорят, когда много, тогда у вас проблемы.
КЛ>>даже если ты будешь разруливать их через отдельные ресурсы где-то будет ветвление на создание (фильтрацию, сборку, как угодно) одного и другого. S>Если я это делаю явным образом, то у меня это ветвление покрывается системой типов, и его статически контролирует компилятор ещё до того, как запустятся тесты.
система типов это только про поля, а что со строками?
это не гибко
КЛ>>я до сих пор не понимаю как добавление ресурсов принципиально что-то меняет в твоей модели и что это у меня за такая модель? S>У вас модель, в которой заранее неизвестно, какая структура ресурса будет получена при обращении по тому или иному ендпоинту. Она типа "динамически" определяется где-то внутри кода непрозрачными правилами.
sql уже стал непрозрачными правилами. "у вас данные отдаются динамически по непрозрачным правилам". дело не сколько в структуре, а вообще в данных.
еше раз — пермисии это такой же фильтр данных как и остальные. разрулить их системой типов хорошо не получится.
пример — у юзера есть 5 основных воркфлоу, в один из которых входит создание внутренних отчетов из таблицы rows, в другой создание анонимизтированных отчетов для регулятора.
внутренний отчет показывает конфиденциальные данные, для регулятора отрезает их.
опиши security-модель для такого? сколько ролей? как все работает?
КЛ>>а кто такое предлагает? я такое не предлагаю. и, кстати, популярный graphql именно это и делает, насколько я понимаю и я это осуждаю. S>Нет, graphQL делает не это.
а что он делает?
КЛ>>не понимаю к чему ты. мы лишь про то, что по токену на беке получаем пермиссии и в зависимости он них отдаем респонс. S>Как мы это будем тестировать?
а как вы тестируете все остальное, что отдает данные на основании пользовательского контекста?
КЛ>>graphql! и да, это бред, но это не то, что я предлагаю S>В graphQL принято несколько неудачных решений, но не потому, что он "выставляет наружу БД".
