Чи справді логіка бізнесу належить на сервері?

Типовим стеком для веб-додатків є база даних, сервер з кодом на стороні сервера та користувач із браузером з HTML / CSS / JavaScript.

Перед розширеним AJAX, MVC, в якому контролером був код на стороні сервера, був застосований. Сервер повинен був направляти запити відповідей на динамічні веб-сторінки (тобто шаблонні HTML-рішення, такі як JSP та ASP). Сервер координує виклики до бази даних та вирішує, яку динамічну сторінку використовувати для відповіді на запит сторінки. Результатом всього цього є те, що сервер виявився бізнес-логікою, хоча бізнес-логіка не сильно пов'язана з ідеєю розміщення сторінок.

Тепер, коли ми переходимо до "Веб 2.0", сервер розміщує статичні сторінки, які використовують JavaScript, щоб заповнити себе та змінити те, що вони представляють. Можливо, в JavaScript. JavaScript часто реалізує службу RESTful, тобто означає, що вона задає запит до бази даних.

Таким чином, сервер залишається за ролями обслуговування фактичних файлів та відповіді на дзвінки AJAX. А відповідати на дзвінки AJAX - це лише керування сеансом та забезпечення безпеки. І справді, те, що користувач навіть повинен бачити, - це дані, які слід вказати в базі даних.

Отже, звідки сервер повинен бути відведений на роль німого посередника, який лише іноді робить щось на зразок надсилання електронної пошти чи звільнення веб-сервісу? Чи може бізнес-логіка жити в JavaScript (коли це не секрет) або жити в збережених процедурах, коли вона є?

Чи буде сенс, можливо, навіть комбінувати сервери та бази даних чи робити ERP-рішення, як SAP, функціонувати як сервери?

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

Є реальні програми, в яких веб-сервер не робить нічого, окрім розкриття API сервера додатків через веб-сервіси або JSON.

Ще до Web 2.0 та AJAX насправді не вважали найкращою практикою змішувати свою бізнес-логіку зі сторінками ASP. Вважалося, що краще мати незалежну бізнес-логіку та мати, щоб частина серверної логіки презентації була в ASP, JSP або будь-якому іншому. Тож справжня зміна від веб-2.0 полягає в тому, що презентаційний шар може бути повністю в JavaScript. Мені так подобається, особисто.

JavaScript часто реалізує службу RESTful, тобто означає, що вона задає запит до бази даних.

Тут ви помилилися. REST - це не CRUD.

Ресурси, що піддаються REST, - це не записи вашої бази даних; вони повністю керовані об'єкти, які ведуть себе відповідно до вашої бізнес-логіки. Коли сервер отримує POST або PUT, він не повинен просто перевіряти та зберігати. Він повинен виконувати все, що підходить для програми.

Простий приклад: програма, схожа на щебетання, отримує твіти у вигляді повідомлень POST на певному контейнері. Потім сервер аналізує контекст ("хто ти?", "Який канал це?") Та вміст ("будь-які хештеги?", Текстові індекси тощо) та зберігає все це у відповідних чергах. Можливо, додає посилання безпосередньо на всіх ваших послідовників.

Це багато роботи, крім простого додавання ресурсу до контейнера, усе це визначено вашою бізнес-логікою. І належить на сервері.

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

однак подумайте про масштабованість, рентабельність та безпеку продукту.

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

Думка підтримувати ділову логіку в JavaScript, що працює на веб-браузерах, де різні браузери потребуватимуть різного javascriopt, декількох версій браузерів тощо ... Чому ця проблема стає складнішою, ніж вона є?

Як сказав Javiar, використовувати REST-підхід як API бази даних для вашого продукту справді не є розумним. Користь інтерфейсу REST полягає в тому, що потім інші люди будуть думати про різні способи використання та запиту вашого інтерфейсу REST. Однак це загальнодоступні логічні ресурси після публікації бізнесу та не низькі рівні запису ресурсів таблиці. Думка зробити такі запити даних низького рівня доступними для HTTP api звучить як кошмар безпеки.

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

Коротка відповідь - це, головним чином, питання управління ризиками, моніторингу та покращення ефективності.

Детально:

Першочерговою причиною №1 є безпека. Клієнтам ніколи не слід довіряти подачу на сервер нічого іншого, крім сміття, і, зберігаючи сторону сервера аспектів безпеки, ви ізолюєте потенційний ризик недобросовісного користувача пошкодити вашу систему. Пам'ятайте, що Javascript повністю сторона клієнта і тривіально змінна, тому ви НЕ МОЖЕТЕ ДОВІРАТИ ВИХІД.

Причина №2 - це розділення проблем. Ваш програміст javascript може бути не експертом з питань безпеки, а ваш гуру безпеки може не настільки чудовий у Javascript. Виділяючи бізнес-логіку від логіки презентації, ви уникаєте перетинати ці проблеми, оскільки javascript не буде дозволено отримувати доступ до ресурсів, що перевищують його рівні дозволів, і отримуватимуть помилки, обробка яких знаходиться в межах програми програмування сценаріїв. Так само хлопець із безпеки не буде налагоджувати Javascript, щоб побачити, як підтримується безпека.

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

Наслідком цього є те, що часто кілька бізнес-процесів будуть використовувати однакові дані, і тому ви можете впровадити кешування на стороні сервера, щоб зменшити загальне завантаження системи, яке може бути неможливим / безпечним, щоб надати клієнтові код доступу.

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

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

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