YM
Сколько проектов, столько подходов
Да нет. Есть стандарты
Size: a a a
2019 June 23
ВТ
Стандарты пишутся людьми, люди могут ошибаться или не учитывать какие-то моменты.
YM
возможно где-то так, но в моём случае какая-то часть бизнес-логики пишется на фронте, так как дёргать ресты по каждому чиху клиента не варик.
Значит плохо спроектированная архитектура. Если кастомер захочет мобильное приложение - прийдется или гибрид пилить или реализовывать ту же бизнес логику в мобильной версии так как бэк не в состоянии это слелать 😒
YM
Стандарты пишутся людьми, люди могут ошибаться или не учитывать какие-то моменты.
☺️ ну ок
ВТ
Значит плохо спроектированная архитектура. Если кастомер захочет мобильное приложение - прийдется или гибрид пилить или реализовывать ту же бизнес логику в мобильной версии так как бэк не в состоянии это слелать 😒
на бумаге всегда всё гладко. если ты не работал в банке, значит ты не представляешь о чём идёт речь
VM
Сколько проектов, столько подходов
а потом мы видим валидацию только на фронте, многомегабайтные обьекты в браузере и прочие прелести
ВТ
а потом мы видим валидацию только на фронте, многомегабайтные обьекты в браузере и прочие прелести
к слову у нас двойная валидация (фронт + бэк), ибо интеграция может упасть
YM
к слову у нас двойная валидация (фронт + бэк), ибо интеграция может упасть
2 side валидация это правильно
A
возможно где-то так, но в моём случае какая-то часть бизнес-логики пишется на фронте, так как дёргать ресты по каждому чиху клиента не варик.
почему не варик?
у меня был опыт, когда по каждому чиху(считай на кадое измененное поле в большой форме) json гоняли на бэк, там всякие калькуляции\валидации - потом назад на клиента. Как бы плохо это ни звучало, но работало отлично. Вначале это было временным решением, но вскоре оказалось, что это нам не доставляет проблем и это наименьшая из проблем.
у меня был опыт, когда по каждому чиху(считай на кадое измененное поле в большой форме) json гоняли на бэк, там всякие калькуляции\валидации - потом назад на клиента. Как бы плохо это ни звучало, но работало отлично. Вначале это было временным решением, но вскоре оказалось, что это нам не доставляет проблем и это наименьшая из проблем.
A
почему не варик?
у меня был опыт, когда по каждому чиху(считай на кадое измененное поле в большой форме) json гоняли на бэк, там всякие калькуляции\валидации - потом назад на клиента. Как бы плохо это ни звучало, но работало отлично. Вначале это было временным решением, но вскоре оказалось, что это нам не доставляет проблем и это наименьшая из проблем.
у меня был опыт, когда по каждому чиху(считай на кадое измененное поле в большой форме) json гоняли на бэк, там всякие калькуляции\валидации - потом назад на клиента. Как бы плохо это ни звучало, но работало отлично. Вначале это было временным решением, но вскоре оказалось, что это нам не доставляет проблем и это наименьшая из проблем.
в банке наверное пользователей конечно побольше будет, но там и возможностей по железу тоже больше.
кстати проект тоже не совсем маленький был - гдето 500к пользователей.
кстати проект тоже не совсем маленький был - гдето 500к пользователей.
VM
asp web forms кстати этот подход использовал - там вобще все состояние на каждый чих на сервер летело.
и нормально работало. в целом нет броблемы с большим количество реквестов, больше вопрос поведения UI с этим
ВТ
почему не варик?
у меня был опыт, когда по каждому чиху(считай на кадое измененное поле в большой форме) json гоняли на бэк, там всякие калькуляции\валидации - потом назад на клиента. Как бы плохо это ни звучало, но работало отлично. Вначале это было временным решением, но вскоре оказалось, что это нам не доставляет проблем и это наименьшая из проблем.
у меня был опыт, когда по каждому чиху(считай на кадое измененное поле в большой форме) json гоняли на бэк, там всякие калькуляции\валидации - потом назад на клиента. Как бы плохо это ни звучало, но работало отлично. Вначале это было временным решением, но вскоре оказалось, что это нам не доставляет проблем и это наименьшая из проблем.
В Сбере клиентов - вся РФ + СНГ ))
ВТ
и нормально работало. в целом нет броблемы с большим количество реквестов, больше вопрос поведения UI с этим
Ну крутили бы спиннер на этот каждый чих
A
В Сбере клиентов - вся РФ + СНГ ))
а затык то где? в каком месте бутылочное горлышко, если запросов много?
VM
Ну крутили бы спиннер на этот каждый чих
ну зачем сразу спиннер, просто отображать по факту подрузки, не обязательно же ждать пока все прям сразу подгрузит
ВТ
ну зачем сразу спиннер, просто отображать по факту подрузки, не обязательно же ждать пока все прям сразу подгрузит
Можно и так, можно и маленький локальный спиннер прям в поле крутить
ВТ
а затык то где? в каком месте бутылочное горлышко, если запросов много?
Есть некоторые ui элементы, пользоваться которыми было бы не очень удобно. К примеру слайдер с ползунком выбора срока и суммы кредита с автом. расчетом предварит. суммы ежемесячного платежа. Каждое смещение ползунка дергало бы бэк и отзывчивость была бы тормозной.
ВТ
Или активация определенного чекбокса в форме должно блокировать какие-то элементы формы, а для этого нужно провести определенные расчеты на основании уже введенных данных. То есть ты жмакнул чекбокс, и только через несколько секунд у тебя задизэйблились элементы, а ты там уже что-то начал вводить.
A
Или активация определенного чекбокса в форме должно блокировать какие-то элементы формы, а для этого нужно провести определенные расчеты на основании уже введенных данных. То есть ты жмакнул чекбокс, и только через несколько секунд у тебя задизэйблились элементы, а ты там уже что-то начал вводить.
несколько секунд? я сейчас глянул - из канады на сервера в рф запрос долетает в пределах 100 ms