PurpleSchool - чат разработчиков

Буду искать альтернативы или в худшем случае сам писать, спасибо

Ребята, день добрый!) Хотел бы у вас всех поинтересоваться по поводу того, как кто организовывает безопасность своего фронтенд приложения на уровне апишки Раньше я делал как: берёшь, создаешь эндпоинт на получение чего-либо. В типизации указываешь то, что получаешь. Ну и дальше если ошибка, то ошибка, или возвращаешь то, что получаешь Но недавно читал несколько интересных материалов на тему того, что фронт не должен доверять Баку в плане получаемых данных и нужно делать упор на безопасность и независимость своего фронтенда от внешних источников, чтобы на уровне инфраструктурного слоя проводились все необходимые валидации и преобразования входящих данных, и в ядро приложения(в доменный слой) попадали гарантированно корректные , провалидированные, актуальные данные В принципе проблема действительно имеет место быть, так как тот факт, что я типизировал ответ от сервера, никак не защищает меня от того, что бэк на своей стороне изменил какое то поле, добавил новое, изменил тип данных и тд. Можно списать на коммуникацию, типо он должен сообщать фронту об актуальных изменениях, но все мы люди, и поэтому хотелось бы взять эту ситуацию под свой контроль. В итоге все эти изменения могут выстрелить в рантайме: чего то будет не хватать, тип данных изменится и тд. В материалах на эту тему автор приводит в пример, как он валидирует данные с помощью zod. Получаешь ответ от сервера, валидируешь, если валидация прошла, по необходимости трансформируешь данные и пускаешь их в ядро приложения =================== Но по внедрению такого слоя логики тоже есть вопросы. Вот у нас сейчас проект - часть банкового приложения под webview. Туда сюда ходят большие наборы данных ииии………. Под каждый эндпоинт нужно писать свой большой валидатор? Плюс с точки зрения ui/ux тоже есть вопросы. Допустим валидация не прошла(типо важное поле случайно на бэке изменили и фронт забраковал эти данные). И что юзеру-то показывать? А-ля «ведутся технические работы» ?😄

Именно к этой идее и пришел, чтобы минимально от внешних обстоятельств зависеть) Валидатор через zod делаете в команде или каким способом? А когда валидация данных не прошла, это же на уровне дизайна решаете? Просто ошибку как-то тоже нужно обрабатывать

у нас сложно, все контракты json schema, валидатор ajv, потом с этого еще и типы генерируются. но тут ты можешь выбирать что хочешь. Главное чтобы это было доступно и фронту и бэку, и в коде было обязательным. Например ты не можешь определить роут без валидаторов.

Прально на музыке

fixed

Не надо валидировать джсоны на фронте. Напишите с бэкендом контракт и работайте по нему

Уже сделал

Использовал адаптер на одном прошлом проекте, но немного для других целей. С бэка приходило полей 30, а мне на фронте по факту нужно было полей 10, остальные служебные, которые бэку нужны были для каких-то его целей. Плюс все поля приходили в кебаб кейсе,а мне нужен был верблюжий стиль. Решил написать маппер, который в себя принимал ответ с бэка, и возвращал только уже мою структуру, которая мне нужна, и по сути весь фронт строился только на моих структурах Я же правильно понял смысл адаптера? Это и есть он? 😄

Да, типо того)