Есть б2б приложение (сайт)
на странице есть сложная таблица, которую юзер может на фронте менять.
для удобства валидацию делать решили на фронте, но вот думаю а надо ли делать на бэке.
В голове сидит парадигма, что бэк должен в себе бизнес логику содержать
Здравствуйте, merge, Вы писали:
M>для удобства валидацию делать решили на фронте, но вот думаю а надо ли делать на бэке. M>В голове сидит парадигма, что бэк должен в себе бизнес логику содержать
M>ваши мысли?
Никакой гарантии что пользователь использует ваш фронт для того чтобы сформировать реквест нет. Поэтому с точки зрения безопасности нужно проверять ввод.
Толстые клиенты появляются в этом индустрии каждые 10 лет, это фиговая идея хранить логику на фронте. Просто потому что ее в другом месте реализуют.
Поэтому иметь ее в двух места — дорога к рассинхоронизации и проблемам.
Здравствуйте, merge, Вы писали:
M>Есть б2б приложение (сайт) M>на странице есть сложная таблица, которую юзер может на фронте менять. M>для удобства валидацию делать решили на фронте, но вот думаю а надо ли делать на бэке. M>В голове сидит парадигма, что бэк должен в себе бизнес логику содержать
M>ваши мысли?
Если следовать принципу контрактного программирования, то БЛ должна бросать исключение при получении не правильных данных. Так что на бэке у вас в любом случае должна быть какая-то проверка входных данных и возврат ошибок если что не так. Валидацию на фронт переносят, если нужно что бы работало быстрее и не загружало сервер запросами, если это не нужно, то можно все сделать на бэке. Так что в вашем случае проверки должны быть в двух местах: на фронте и бэке.
Здравствуйте, merge, Вы писали:
M>Есть б2б приложение (сайт) M>на странице есть сложная таблица, которую юзер может на фронте менять. M>для удобства валидацию делать решили на фронте, но вот думаю а надо ли делать на бэке. M>В голове сидит парадигма, что бэк должен в себе бизнес логику содержать
M>ваши мысли?
длеать и там, и там.
на фронте для удобства пользователя, на бэке для сохранения инвариантов системы.
В идеале должен быть набор правил, который и на беке проверяет данные и на фронт транслируется (без участия человека) для таких проверок.
Проще всего сделать отдельный вызов, который валидирует форму и постоянно вызывать его (когда пользователь что-то меняет). Если сервер не совсем тугой, то будет за долю секунды отрабатывать, в принципе на юзабилити не скажется. Ну и на сабмит, конечно, проверять всё обязательно.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, merge, Вы писали:
M>>Есть б2б приложение (сайт) M>>на странице есть сложная таблица, которую юзер может на фронте менять. M>>для удобства валидацию делать решили на фронте, но вот думаю а надо ли делать на бэке. M>>В голове сидит парадигма, что бэк должен в себе бизнес логику содержать
M>>ваши мысли? G>длеать и там, и там. G>на фронте для удобства пользователя, на бэке для сохранения инвариантов системы. G>В идеале должен быть набор правил, который и на беке проверяет данные и на фронт транслируется (без участия человека) для таких проверок.
да, было бы хорошо иметь такие правила чтобы без участия человека.
только слабо себе представляю как это должно выглядеть.
Если что бэк дотнет коре, а фронт на реакте
Здравствуйте, merge, Вы писали:
M>ваши мысли?
Двойная валидация это стандарт.
Валидация на фронте ускоряет обратную связь для пользователя, но если это не критично, то ее можно и опустить.
Валидация на бэке делается обязательно и защищает от ввода не валидных данных в случае если на фронте что-то развалилось или кто-то послал некорректный запрос.
Здравствуйте, merge, Вы писали:
M>Есть б2б приложение (сайт) M>на странице есть сложная таблица, которую юзер может на фронте менять. M>для удобства валидацию делать решили на фронте, но вот думаю а надо ли делать на бэке. M>В голове сидит парадигма, что бэк должен в себе бизнес логику содержать
M>ваши мысли?
Если говорить про Джаву, то есть библиотеки, которые позволяют генерить на UI правила валидации на основе правил, заданных в аннотациях Java Bean Validation на бэке. Это позволяет единожды декларативно описать правила валидации, которые будут использоваться и на бэке и на фронте. Еще проще, если используется генерилка типа JHipster, но это только для простых проектов, там тоже декларативно описываешь правила валидации в одном месте — в описании модели.
Здравствуйте, merge, Вы писали:
M>ваши мысли?
Если соединение позволяет можно сделать валидацию на сервере и делать ajax вызовы с клиента.
Вообще клиенту удобнее с валидацией?
Здравствуйте, merge, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, merge, Вы писали:
M>>>Есть б2б приложение (сайт) M>>>на странице есть сложная таблица, которую юзер может на фронте менять. M>>>для удобства валидацию делать решили на фронте, но вот думаю а надо ли делать на бэке. M>>>В голове сидит парадигма, что бэк должен в себе бизнес логику содержать
M>>>ваши мысли? G>>длеать и там, и там. G>>на фронте для удобства пользователя, на бэке для сохранения инвариантов системы. G>>В идеале должен быть набор правил, который и на беке проверяет данные и на фронт транслируется (без участия человека) для таких проверок.
M>да, было бы хорошо иметь такие правила чтобы без участия человека. M>только слабо себе представляю как это должно выглядеть. M>Если что бэк дотнет коре, а фронт на реакте
Такое работает на asp.net mvc\pages. В разметке генерируются атрибуты валидации из атрибутов на классах модели. Думаю можно найти готовый пакет, который генерирует "модель валидации" для клиента.
Здравствуйте, merge, Вы писали:
M>В голове сидит парадигма, что бэк должен в себе бизнес логику содержать
Всё верно, валидация входных данных — это часть бизнес-логики и должна быть на бэке. Фронтовая валидация относится к UX, пользователь получает вменяемое сообщение и сразу, а не 400 и после отправки формы на сервер.
