🔥- Я только спросить! - В очередь!🔥
На одном из проектов была задача: дать юзерам возможность присылать API-запросами в приложение на Баббл товары в больших количествах (до 40-50 тыс. шт.). Создать большое количество товаров с помощью Data API не проблема: за 20 с создавалось 250 записей с 12 заполненными полями, но вопрос: что станет с сайтом, если запросы отправят сразу 10, 20 и более пользователей?
Такие запросы будут выполняться параллельно, постепенно расходуя capacity приложения. Что произойдет, когда процессы заполнят всю память? Они встанут в очередь, и начнут выполняться последовательно! Круто?! Не совсем🤪) Представим что некоторые действия пользователя на фронте зависят от процессов на бэке. Что ждет пользователя, если на бэке выстроится очередь? Долгий ответ сайта) В особо тяжелых случаях браузер отобразит вам сообщение "app too busy"😆
Чтобы не дать пользователям положить ваш сайт, используйте очередь.
Спецы советуют переносить сложные процессы с фронта на бэк, и это имеет смысл. Но на бэке они не всегда должны выполняться параллельно🙃
С тяжелыми процессами на бэке можно поступить следующим образом:
1) настройте процесс так, чтобы вместо запуска отдельного API workflow, юзер складывал свое задание в БД (создайте для этого отдельную таблицу "Очередь")
2) запустите цикл, который с определенной частотой (частоту вычисляют отталкиваясь от показаний на вкладке Logs - Capacity) будет запускать обработку очередной записи из таблицы "Очередь" (убедитесь, что цикл не отвалится, если в таблице закончатся записи).
Тогда ваше приложение будет последовательно выполнять задание за заданием, экономно расходуя выделенные мощности.
При таком подходе нагрузка на сайт будет более равномерной, результат действий пользователя предсказуемым, а на почту перестанут приходить письма от Bubble с предупреждением о максимальной нагрузке на ваш сайт.
Здоровья вашим аппкам)
Напишите, пользуетесь ли вы этим способом, и как бы вы его доработали👍
🔥Ставь реакцию, если понравилось🔥
Post #25
920
- 🔥 22
- ❤ 3
- 👍 3