Коли доцільно робити обчислення в передній частині?

Моя команда розробляє додаток для фінансування на веб-сайті, і з колегою було чимало суперечок, де зберегти розрахунки - суто в бек-енді чи тримати їх і в передній частині?

Коротке пояснення: ми використовуємо Java (ZK, Spring) для фронтального і Progress 4gl для бек-енд. Розрахунки, що передбачають деяку жорстку математику та дані з бази даних, зберігаються в бек-енді, тому я не кажу про них. Я говорю про ситуацію, коли користувач вводить значення X, воно додається до значення Y (показане на екрані), а результат відображається в полі Z. Чисті і прості операції jQuery-ish, я маю на увазі.

Тож, що було б найкращою практикою тут:

1) Додайте значення за допомогою JavaScript, що дозволяє економити від переходу до бек-енду і назад, а потім перевіряє їх на задній частині "при збереженні"?

2) Тримайте всю бізнес-логіку на одному місці - отже, виведіть ці значення в бек-енд і зробіть там обчислення?

3) Робіть обчислення в передній частині; потім відправте дані в бек-енд, підтвердіть їх там, зробіть обчислення знову і лише якщо результати дійсні і рівні, покажіть їх користувачеві?

4) Щось ще?

Примітка. Ми виконуємо деякі основні перевірки на Java, але більшість із них все ще знаходиться в бек-енді, як і вся інша бізнес-логіка.

Збільшення даних, які будуть надіслані шляхом перерахунку всього в задньому плані, не буде проблемою (невеликий розмір XML; сервери та пропускна здатність витримують збільшений обсяг операцій, що виконуються користувачами).

programming-practices web-applications front-end

— ІгнасК
джерело

Правило великого пальця: коли в ньому використовується сильно набрана мова.

— День

Автоматизоване тестування блоків буде простіше, якщо вся логіка знаходиться на звороті. Якщо 90% має бути задньою частиною, а 10% може бути задньою, то я б поставив 100% задній.

— Ян

@Ian: ви також можете провести автоматичне тестування одиниць для кодів переднього кінця, якщо ви добре структуруєте код.

— Лежати Райан

Правило великого пальця: Кожен раз, коли ви можете від нього піти.

— goldilocks

Правило: припустимо, що користувач зламає ваш JavaScript і робить власні розрахунки. З точки зору безпеки, розрахунки потрібно робити на зворотному боці. Ви можете зробити і те й інше: JS може надати швидший зворотній зв'язок, але обчислення, які насправді рахуються, робляться на сервері.

Відповіді:

Як завжди, такі рішення передбачають компроміс між різними цілями, деякі з яких суперечать один одному.

Ефективність може запропонувати виконувати обчислення в передній частині - і тому, що таким чином комп’ютер користувача споживає більше енергії, а ваш сервер витрачає менше, а також тому, що користувач бачить швидший зворотний зв'язок, що покращує користувацький досвід.
Безпека вимагає, щоб будь-які операції зі зміни стану не могли покладатися на дані, які перевіряються чи обчислюються на клієнтському комп'ютері, оскільки клієнтський комп'ютер може перебувати під контролем зловмисного зловмисника. Тому ви повинні перевірити все, що надходить з ненадійних джерел на стороні сервера.
Ефективність програмування та ремонтопридатність підказує, що ви не повинні робити одне і те ж обчислення двічі через витрачені зусилля.

Поверхово це звучить так, ніби все має бути зроблено на сервері, але це не завжди так. Якщо ви можете легко підтримувати дублюваний код (наприклад, автоматично генеруючи валідатор javascript з вашої валідатора Java-сервера), то повторення обчислень може бути хорошим рішенням. Якщо дані, пов'язані з цим, не мають значення, наприклад, якщо користувач може обдурити лише себе, а не ви, якщо вони маніпулюють значеннями, тоді перевірка на сервері не потрібна. Якщо у вашому часі реакції переважають зовсім інші вузькі місця, так що затримка в зворотному напрямку не помітна, то міркування щодо UX не є визначальними і т. Д. Тому ви повинні врахувати, наскільки сильний кожен із цих тиску у вашій ситуації, і прийняти відповідне рішення .

— Кіліан Фот
джерело

Я хотів би додати, що

Programming efficiency and maintainability suggests that you shouldn't do the same computation twice because of the wasted effort.

це невірно, оскільки [1] Перевірка на передній частині може забезпечити швидкий зворотний зв'язок з користувачем, щоб внести виправлення, якщо це необхідно. [2] Перевірка на задній план не настільки чуйна, і, таким чином, не надає користувачеві найкращої можливості вносити виправлення. Користувачеві потрібно буде зачекати і повторити більше роботи. Тож я думаю, що дві перевірки не зовсім однакові.

— ПоінформованоAA

Це не те , що я хотів би отримати по - ремонтопридатність робить на увазі «не повторюватися», і в Відповідно до цього принципу повторення, звичайно , погано. Якщо не було інших міркувань, ви не повинні цього робити. Справа в тому, що це, однак, часто є хорошою ідеєю, оскільки є й інші міркування, які суперечать цьому принципу, тобто краща зручність використання завдяки швидкому повороту.

— Кіліан Фот

@randomA Ви неправильно застосовуєте цей принцип, якщо ви маєте на увазі, що щось, що потрібно перевірити на сервері, слід розраховувати лише на сервері, тому що якщо "підтверджене значення сервера" (або що-небудь залежне від нього) повертається до клієнта, то в якийсь момент, відправлений назад на сервер, вам доведеться все-таки перевірити його знову - марно. Або ж вам потрібна якась безпечна посилання, яка може бути ще неефективною. Я б сказав, якщо ви можете зробити розрахунок на клієнта, зробіть це на клієнті , але також ніколи не довіряйте тому, що вам каже клієнт .

— goldilocks

@goldilocks Те, що ви сказали жирним шрифтом, - це теж те, що я згоден, ви повинні все підтвердити на зворотному боці. Моя думка полягала в тому, що: перевірка на передній панелі більш чуйна, тому не зовсім така, як перевірка на бек-енді.

— Поінформовано

Існують вагомі причини, щоб робити обчислення в бекенді

Логіка бізнесу не належить до шару презентації
Бізнес-логіка в JavaScript становить загрозу
Ви припускаєте, що існує взаємний зв'язок -> один-задній, який не завжди відповідає дійсності , слід вважати, що " бек-енд" може бути здатним або обслуговувати більше, ніж один передній додаток, тому ви нічого не можете припускати.
Якщо для обчислень використовується велика кількість даних, було б неефективно утримувати їх у передній частині
Якщо для обчислень використовується база даних, ви не зможете повторити її в передній частині

Моя рекомендація

Потрібно, щоб база даних застосовувала стільки правил бізнесу, скільки можливо в цій моделі, включаючи зовнішні ключі, первинні ключі, обмеження та тригери перевірки
Запропонуйте бізнес-шару винятки, коли ділові правила не виконуються (або тому, що база даних повернула помилку, або тому, що сам бізнес-рівень підтвердив дані)
Якщо і лише якщо час відповіді неприйнятний, робіть перевірки або попередню обробку за допомогою Ajax (робота не буде реально виконана в JavaScript, це буде виконано в бекенде, не потребуючи перезавантаження сторінки)
Ви можете зробити просту перевірку в JavaScript, наприклад, не допускаючи порожнього значення або занадто довгих значень або поза діапазоном (для останнього, можливо, ви захочете генерувати діапазони в бек-енді)

— Тулан Кордова
джерело

Проблема з тим, що база даних виконує правила ведення бізнесу, - це повідомлення про порушення на передній частині! Якщо передня частина виконує ділові правила, вона може швидко надіслати користувачеві значні повідомлення про помилки. Якщо це робить зворотний кінець, існує багато незграбних двосторонніх перевезень між передньою та задньою частинами, як повідомляються про помилки одна за одною.

— Джеймс Андерсон

@JamesAnderson Більше немає "передового". До однієї бази даних може бути декілька передніх чи декількох баз даних до декількох фронтових. Крім того, наявність бізнес-правил примусового виконання не означає, що це робити заборонено. Я підкреслив, що у другій кулі.

— Tulains Córdova