Багато асинхронних дзвінків проти одного виклику в API

Ми розробляємо API REST, який, серед інших, буде використовуватися в інтерфейсі HTML5 через JavaScript. Додаток призначений для використання в організації та зазвичай має близько 300 користувачів, але ми хочемо масштабувати масштаб до 1000 користувачів.

Зазвичай підключення до API буде здійснюватися в межах локальної мережі, тому якість та затримка з'єднання будуть хорошими, хоча не виключається випадкове використання через Інтернет, де з'єднання можуть бути повільнішими та з більшим запізненням через 3G / 4G.

Ми думали два варіанти:

1. Фронтенд здійснить кілька одночасних асинхронних дзвінків в API для завантаження різних компонентів інтерфейсу.

   • Плюси: простота
   • Мінуси: більше підключень до сервера.

2. Контролер інтерфейсу здійснює один виклик API, передаючи його як параметри, об'єкти яких потрібно отримати.

   • Плюси: Лише одне підключення до сервера, хоча сервер зробить кілька підключень до бази даних.
   • Мінуси: Потрібні механізми як в інтерфейсі, так і в API. Це ускладнює дизайн.

Подальші пояснення: Існуватимуть різні ресурси ... / Продукт ... / Місцеположення тощо. Ці ресурси можуть бути отримані поодинці, але буде ще один абстрактний ресурс ... / екран? Продукт і локації, які отримають обидва в одному дзвінку.

Варіант 1 (кілька викликів асинхронізації) - найкращий вибір, оскільки:

1. кожен окремий дзвінок є власною сутністю , тому ви можете повторно спробувати індивідуально, якщо щось трапиться з ладу. У монолітній архітектурі "один виклик", якщо одна справа не вдається, ви повинні зробити весь дзвінок заново
2. код серверної сторони буде простішим: знову ж таки, модульність , це означає, що різні розробники можуть працювати на різних ресурсах API
3. У типовому шаблоні MVC не має сенсу один виклик API завантажувати кілька окремих ресурсів ; наприклад, якщо ви подаєте запит на /productsотримання списку товарів, який потрібно відобразити на сторінці, а також ви хочете відобразити список місць, де продаються популярні товари, у вас є два окремі ресурси: Productі Location. Незважаючи на те, що вони відображаються на одній сторінці, ви не можете логічно телефонувати на дзвінок, /productsа також повертати місця
4. ваші звіти про реєстрацію / використання будуть простішими в модульному підході. Якщо ви подаєте запит /productsі також завантажуєте місця, ваші файли журналів будуть дійсно заплутаними
5. якщо у вас є проблеми з певним ресурсом, підхід одноразового виклику призведе до розриву всієї сторінки, і вашим користувачам не буде очевидно, що зламалося - а це означає, що для вирішення проблеми вашій команді буде потрібно довше; Однак у модульному підході, якщо одна річ порушиться, буде дуже очевидно, що зламалося, і ви зможете це виправити швидше. Він також не зіпсує решту сторінки (якщо речі занадто тісно не зчеплені ...)
6. вносити зміни взагалі буде простіше, якщо речі будуть розділені; якщо у вас один ресурс завантажується одним викликом API, буде складніше зрозуміти, як не порушувати речі, коли ви хочете щось змінити

Вся справа в тому, що ресурси окремі, і в API REST повернення багатьох окремих ресурсів з одного шляху API не має сенсу, навіть якщо ви "зберігаєте з'єднання з сервером". До речі, використання параметрів для умовного завантаження (різних) ресурсів не є RESTful.

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

PS - Не заздалегідь оптимізуйте «з'єднання з сервером», особливо коли HTTP-з'єднання надзвичайно низькі, а ви перебуваєте в локальній мережі. Таке мислення, замість вибору більш простого дизайну від кажана, позбавить вас проблем.