Наскільки безпечні приховані запити AJAX, які підробляють продуктивність?

Що таке прихований запит AJAX?

Я помітив збільшення використання прихованих запитів AJAX, призначених для того, щоб зробити дії користувача негайно. Я буду називати цей тип запиту AJAX як неблокуючий. Це запит AJAX, зроблений без усвідомлення користувачем, що це відбувається, він виконується у фоновому режимі, і операція проходить безшумно ( немає верболозу, який би вказував на успішне завершення дзвінка AJAX ). Мета полягає в тому, щоб операція виявилася, що це сталося негайно, коли вона дійсно не закінчилася.

Ось приклади неблокуючого запиту AJAX;

• Клацання користувача видаляють на колекції електронних листів. Елементи одразу зникають із папки "Вхідні", і вони можуть продовжувати інші операції. Тим часом запит AJAX обробляє видалення елементів у фоновому режимі.
• Користувач заповнює форму для нових записів. Кліки зберегти. Новий елемент з’являється у списку негайно. Користувач може продовжувати додавати нові записи.

Для уточнення, ось приклади блокування запиту AJAX;

• Клацання користувача видаляють на колекції електронних листів. З'являється курсор пісочного годинника. Запит AJAX робиться, і коли він відповідає, курсор пісочного годинника вимикається. Користувач повинен зачекати секунду, щоб операція завершилася.
• Користувач заповнює форму для нових записів. Кліки зберегти. Форма стає сірою з анімацією навантажувача AJAX. З'являється повідомлення "Ваші дані були збережені", і нова запис відображається в списку.

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

Ризик прихованих запитів AJAX

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

Наприклад, неблокуючий приклад;

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

По черзі, блокуючий приклад;

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

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

То чому він стає таким популярним?

Facebook, Google, Microsoft, і т.д .. і т.д .. всі ці великі домени все частіше використовують Неблокована запити AJAX , щоб зробити операції з'являються , що вони виконуються миттєво. Я також спостерігав збільшення редакторів форм, у яких немає кнопки збереження або надсилання . Як тільки ви вийдете з поля або натисніть клавішу Enter. Значення зберігається. Немає Вашого профілю, оновленого повідомлення чи кроку збереження.

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

Це веб-сайти, які використовують неблокуючі дзвінки AJAX для імітації чутливих додатків, несучи зайвий ризик ціною швидкої появи?

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

Це не стільки "фальшива" вистава, скільки реальна чуйність. Є кілька причин, чому це популярно:

• Підключення до Інтернету сьогодні досить надійні. Ризик відмови запиту AJAX дуже низький.
• Операції, що виконуються, насправді не важливі для безпеки. Якщо ваші електронні листи не видаляються на сервері, найгірше, що трапляється, вам доведеться видалити їх знову наступного разу, коли ви перейдете на сторінку.
• Ви можете розробити свою сторінку, щоб скасувати дію, якщо запит не вдався, але насправді не потрібно бути таким тонким, оскільки це означає, що ваше з'єднання з сервером порушено. Простіше сказати "З’єднання втрачено. Неможливо зберегти останні зміни. Спробуйте знову пізніше".
• Ви можете розробити свою сторінку, щоб дозволити лише один очікуваний запит AJAX, щоб ваш стан не надто синхронізувався з сервером.
• Веб-переглядач попереджає вас, якщо ви намагаєтесь закрити або перейти від сторінки, поки запит AJAX очікує.

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

Клієнт електронної пошти насправді є прекрасним прикладом для цього: Коли у мене є список з 5 електронними листами і вибрано верхню, я очікую, що при натисканні DELтри рази перші три електронні листи видаляються. З функцією "розблокування AJAX" це працює чудово - щоразу, коли я натискаю клавішу, вибране повідомлення електронної пошти видаляється негайно. Якщо щось піде не так, відображається помилка, або знову неправильно видалені електронні листи відображаються АБО сторінка перезавантажується, щоб позбутися непослідовного локального стану.

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

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

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

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

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

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

Amazon AWS застосовує такий підхід: коли ви зупиняєте / запускаєте екземпляр, прапорець, що дозволяє вам вибрати, перетворюється на спінер (тому ви не можете нічого з цим зробити протягом декількох секунд), але це не блокує вас від взаємодія з іншими примірниками.

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

Ви кажете: "Зараз код JavaScript виявляє, що запит AJAX виявився невдалим. Сценарій може відображати повідомлення про помилку, але це справді безглуздо."

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

Мій 2c: є ситуації, коли краще проводити, як ви сказали, "неблокуючі" операції Ajax та інші, коли це поганий вибір дизайну. Приклад: голосування відео YouTube. Ви дійсно не хочете, щоб будь-яка частина сторінки була заблокована, коли ви клацаєте на маленьких початках там. Краще мовчки відмовитися. Навіть повідомлення про підтвердження було б надмірним вбивством. Однак ваш приклад зі видаленням електронної пошти я визнав би обов'язковим для блокування запиту Ajax.

Mongo DB робить щось подібне (і це можна вважати прикладом програми для настільних програм). У них є різні "Писати проблеми" для своїх операцій, і ви можете налаштувати її на різні значення для кожної операції, починаючи від "повернення відразу і не чекайте нічого" до "блокування до моменту підтвердження успішної передачі мережі та потім поверніться "до" дочекатися, коли вміст буде належним чином запланований для запису диска на віддаленій машині до повернення ". Очевидно, що якщо ви робите для клієнта Desktop товстий клієнт (як, наприклад, C ++) за допомогою драйвера Mongo, ви встановите найменшу стурбованість у записі щодо операцій db мінімальної «критичності» (наприклад, перевірки нової електронної пошти) та інших, які мають більш суворі проблеми запису. .

Хоча я бачу корисність блокування Ajax, я згоден з вами, що це відбувається занадто багато. На момент існування принаймні одного відомого сайту "соціальної мережі", який би це зробив для завантаження фотографій. Ви вибрали свою фотографію для завантаження, а потім бамбуйте, одразу вона скаже вам, що вона зроблена, а потім досить впевнена наступного дня, коли ви хочете додати ще кілька фотографій (або використати те, що ви думали, що вже додали), це його ніколи не було знайдено. Пізніше вони відмовилися від цього і фактично зайняли час, щоб дочекатися відповіді (і ви дійсно іноді отримуєте повідомлення типу "не вдалося завантажити фото, спробуйте пізніше").