Плюси / мінуси між акцентом на обробці на стороні клієнта або на сервері

Чому я б хотів написати веб-додаток з великою кількістю обробних серверів?

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

Я дуже мало бачу написання веб-додатків, окрім того, що пишуть на стороні сервера і трактують сторону клієнта лише як вигляд . Чому я колись хотів би це зробити? Єдиною перевагою, яку я бачу, є те, що я можу писати будь-якою мовою ( http://www.paulgraham.com/avg.html ).

Є два основні питання.

1. Перший простий - ви зазвичай не знаєте, які ресурси доступні на стороні клієнта. Якщо для обробки чогось потрібно 1,5 Гб, чи можете ви дійсно натиснути це на невідомий клієнтський браузер (IE, Safari, Opera, Firefox тощо) на невідомому платформі клієнта? Чи оцінить клієнт свою систему, коли ви її перевантажуєте?

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

В першу чергу - безпека . Висуньте всю свою логіку до клієнта, і це чесна гра для хакерів і подвигів.

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

Сторона клієнта проти сервера

Обробка на стороні клієнта відповідає більш популярним стандартам REST, а також MVC на відміну від підходів на основі сторінки та SOAP. Поява цих тенденцій та зосередження уваги на AJAX та Html-RIA, сценарії на стороні клієнта зростають та користуються більшою популярністю; однак, через проблеми безпеки та можливості клієнта, сценарії на стороні клієнта мають певну нішу і не повинні використовуватися для всього.

Міркування:

Мобільний

Якщо великий сегмент вашої цільової аудиторії становитиме мобільні користувачі, важку обробку слід залишити на сервері.

Послідовність крос-браузера

Веб-стандарти пройшли довгий шлях, і це може не викликати особливих проблем, але кожен веб-розробник знає, що IE 6,7, 8, а іноді і Safari можуть діяти смішно на стороні клієнта - певні функції можуть не працювати через обмеження безпеки та інші через невиконані стандарти. Важливо також зазначити, що кінцевий користувач може налаштувати браузер на певні обмеження або навіть повністю відключити обробку на стороні клієнта (без JavaScript!). Якщо послідовність - це вимога для 100% користувачів (і особливо, якщо ви робите щось неортодоксальне), сервер є найбільш важливим.

Безпека

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

UI / UX

Клієнтська обробка залишається для користувальницького інтерфейсу та створення багатих інтернет-додатків (RIA). Він використовується для створення анімації, ефектів, взаємодії з користувачами, а також для динамічного завантаження вмісту через дзвінки AJAX замість повторного завантаження цілої сторінки.

В першу чергу це буде дублювання зусиль. Швидше за все, будь-які дані клієнта будуть знову перевірені та оброблені на рівні сервера.

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

Однак я вважаю, що для покращення користувацького інтерфейсу можна зробити певну логіку на рівні клієнта.

Ви маєте рацію, навіщо надсилати дані на сервер, якщо вони не є повними або неправильними. Легко перевірити необхідні поля або чи правильно відформатовані телефони чи адреси електронної пошти. Я ніколи не любив надсилати форму, а потім чекав 5 секунд, щоб сказати, що я забув ввести поле. Таку обробку, звичайно, виконайте на клієнті та переконайтесь, що вона правильна та використовуючи логіку на стороні клієнта для швидкого реагування на користувача. Як ви вже зазначали, бонусним побічним ефектом буде те, що ваш сервер повинен мати справу з менш поганими запитами на дані. Але НЕ, сервер все ще повинен перевірити, тому ви копіюєте логіку. Але ваші користувачі будуть щасливішими.

Тут є тонка лінія. Проста логіка перевірки Гаразд, основна логіка бізнесу не в порядку.

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

   а) Клієнт / Презентація - HTML та Javascript, можуть містити ActiveX / Flash / аплети Java / Silverlight. Я вийду на кінцівку і додаю власні мобільні додатки, які спілкуються із заднім сервером. В основному роль цього шару полягає у наданні інтерфейсу для користувача системи для взаємодії з ним.

   b) Бізнес-логіка - PHP / RoR / Java, де дані клієнта збираються, обробляються та зберігаються і де запити клієнтів на дані обробляються та відправляються назад клієнту

   c) Backend Data Store - забезпечує постійне зберігання системної інформації

2. Тож де ви робите валідацію у всіх шарах. Чому?

   а) Сторона клієнта - переконайтеся, що користувач вводить правильні дані, обов'язкові поля тощо

   б) Бізнес-логіка - фільтрувати, санітувати та перевіряти клієнтські дані. Виконайте більш складні правила ведення бізнесу, щоб забезпечити належну форму даних для зберігання. Деякі з валідацій, зроблених на передньому кінці, тут повторюються, через те, що можуть бути різні клієнти, наприклад, браузери, Javascript можна відключити. Наприклад, він також може приймати дані з різних джерел через API, тому все це потрібно перевірити.

   c) Зберігання даних Backend - обмеження забезпечують належну форму даних для зберігання та подальшого пошуку.

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

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

Коли ви повністю формуєте свою поведінку на стороні клієнта (скажімо, з Javascript), SEO може стати проблемою.

Веб-рішення, які зберігають багато на сервері, легше можуть зберігати певний вміст, розміщений за певною URL-адресою (як правило, RESTful) таким чином, що видно пошуковим системам.

Це також означає, що відвідувач може зробити закладку певної сторінки. Ви пробували це у Facebook?

Цей матеріал можна вирішити, але він, як правило, вбудовується в додатки, які роблять багато на сервері (RAILS, WordPress тощо), тоді як якщо ви будуєте, скажімо, REACT, вам доведеться перестрибувати обручі.

Причина - стабільність .

На стороні сервера я можу вибрати стабільні компоненти. Зазвичай це означає, що я вибираю Java та купу дуже ретельно підібраних бібліотек, таких як FreeMarker. Потрібно сказати, що кожна бібліотека, окрім стандартних бібліотек Java, трактується як одноразова, тому я отримую доступ до зовнішніх бібліотек через саморобну обгортку. Це означає, що я можу легко змінюватися з однієї бібліотеки в іншу, якщо виникає вимога.

Щоразу, коли я оновлюю Java до нової версії, вона зазвичай працює добре, тому що Java є надзвичайно стабільним компонентом навіть у великих оновленнях версій. А також, кожен сервер, на якому я працює, має однакову версію Java. Не кожен клієнт працює однаковою реалізацією JavaScript.

З боку клієнта я не можу вибрати стабільні компоненти. Виробники браузерів змусять мене вибрати JavaScript, мову, яка мені особливо не подобається, але ту, яку я змушений використовувати. (І не кажіть мені про мови, зібрані в JavaScript, вони жахливі!) Реалізація JavaScript у кожного браузера різна. Це означає, що я перевіряю свій продукт на кожній підтримуваній версії браузера.

Моє рішення? Я виконую стільки обробок, скільки можу на стороні сервера, а клієнтська сторона - це лише легка обгортка, яка надсилає дані на сервер і отримує дані з сервера у вигляді фрагментів JSON та HTML. Уникати XML; використовувати замість JSON.

Я не роблю шаблонів на стороні клієнта; Я передаю вміст на сервері до фрагмента HTML, який я потім присвоюю, використовуючи .innerHTMLатрибут для різних елементів-заповнювачів на стороні клієнта. Це забезпечує стек технологій максимально простим, тому що мені не потрібні два двигуни шаблону (Java і JavaScript).

Недолік - очевидно, затримка швидкості світла; половина секунди затримки не рідкість між континентами.

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

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