SP
ну то есть, ты должен задаться вопросом "а что плохого если у человека имя 4 килобайта"?
Size: a a a
2021 January 14
SF
Human Human
Такой вопрос. Вы делаете валдиацию данных на беке, которая нужна чисто для ограничения размера? Типа макс. длина описания или email и тд. Или полагаетесь на констрейнты в базе?
Да. Чуть ли не на каждом слое.
SP
Да. Чуть ли не на каждом слое.
и зачем? потому что у тебя в базе какой-нибудь varchar(255)?
SP
ну то есть, вот приходит тебе чел с самым длинным именем в мире (~1000 символов). Ты его не пустишь?
SF
ну то есть, вот приходит тебе чел с самым длинным именем в мире (~1000 символов). Ты его не пустишь?
Не я не пущу, а бизнес не пустит. Пример с именем неудачный
HH
ну то есть, ты должен задаться вопросом "а что плохого если у человека имя 4 килобайта"?
Хз, вроде в моем кейсе неплохо. Но ограничив тело запроса - я ограничиваю даже те места, где нужно послать и 50мб типа.
SP
Не я не пущу, а бизнес не пустит. Пример с именем неудачный
интересно какой это бизнес такие вещи продумывает. Продакт бывший QA?
SF
и зачем? потому что у тебя в базе какой-нибудь varchar(255)?
Потому что часто бывает так, что на разных стендах разные хранилища и полагаться что в каком из них установлено вменяемое ограничение крайне сомнительно
SF
интересно какой это бизнес такие вещи продумывает. Продакт бывший QA?
Финансы
SP
Финансы
и какое отношение длинные имена имеют в этом домене? на какие бизнес ограниченя это влияет?
SP
Потому что часто бывает так, что на разных стендах разные хранилища и полагаться что в каком из них установлено вменяемое ограничение крайне сомнительно
а у тебя схему базы люди руками на разных стэндах собирают раз такие сомнения есть?
SF
и какое отношение длинные имена имеют в этом домене? на какие бизнес ограниченя это влияет?
Я же сказал что пример стиснем неудачный
HH
Вопрос к тому, что у меня уже есть varchar(255) в базе.
+ валидация на фронте.
Почему бы мне просто не обрабатывать ошибки констрейнта базы в случае если кто-то пользуется API без фронта.
+ валидация на фронте.
Почему бы мне просто не обрабатывать ошибки констрейнта базы в случае если кто-то пользуется API без фронта.
˸A
интересно какой это бизнес такие вещи продумывает. Продакт бывший QA?
CRM, которые такого пользователя не пропустят
SF
Human Human
Вопрос к тому, что у меня уже есть varchar(255) в базе.
+ валидация на фронте.
Почему бы мне просто не обрабатывать ошибки констрейнта базы в случае если кто-то пользуется API без фронта.
+ валидация на фронте.
Почему бы мне просто не обрабатывать ошибки констрейнта базы в случае если кто-то пользуется API без фронта.
+ на фронте
Это не плюс
Это не плюс
SF
а у тебя схему базы люди руками на разных стэндах собирают раз такие сомнения есть?
Нет
DT
Human Human
Вопрос к тому, что у меня уже есть varchar(255) в базе.
+ валидация на фронте.
Почему бы мне просто не обрабатывать ошибки констрейнта базы в случае если кто-то пользуется API без фронта.
+ валидация на фронте.
Почему бы мне просто не обрабатывать ошибки констрейнта базы в случае если кто-то пользуется API без фронта.
Fail fast
HH
Fail fast
Это про производительность?
DT
Human Human
Это про производительность?
Это про то, что не нужно делать бессмысленных действий, в данном случае ходить в базу, если данные поломаны
HH
Это про то, что не нужно делать бессмысленных действий, в данном случае ходить в базу, если данные поломаны
Бессмысленное действие или нет - сильно зависит от контекста.
В моем случае это 3 раза описывать констрейнт в разных местах
В моем случае это 3 раза описывать констрейнт в разных местах