Комментарии 6
5 секунд было всегда достаточно
сегодня да - завтра новые эксперименты и гадания на кофейной гуще?
непонятно, а юзер-то узнает, что у него интервалы изменились? Задача выглядит как бизнесовая, а не фронтовая, в первую очередь.
Спасибо за комментарий. Согласен с Вами. К сожалению бек изменить нельзя, и подсказать точно время обновления интервалов мне не смогли, поэтому пришлось гадать на кофейной гуще.
Юзер узнает о смене интервалов, так как при их обновлении интервалы скинуться и ему придется заново выбирать интервалы.
Задача действительно больше бизнесовая, но к сожалению имеем то, что имеем. Задача есть в спринте, бизнес хочет получить результат, соответственно пришлось выполнять, надеюсь, что кому то мой опыт будет полезен.
Так же мне понравилась идея @xxxphilinxxx c отслеживанием активности пользователя, чтобы не грузить сервер тяжелыми запросами.
В итоге просто бомбардируете сервер тяжелыми запросами, да еще и подгоняете интервалы под нюансы реализации бэка: таких глубоких сведений у фронта быть не должно, это слишком жесткая связь за пределами интерфейса. Ну и если сейчас 5 секунд достаточно, то когда-нибудь под нагрузкой их перестанет хватать и решение будет работать со сбоями.
Какие я вижу варианты:
На бэке при получении формы заказа возвращаем ошибку "интервал не существует", на фронте при ее получении запрашиваем интервалы и просим пользователя вернуться и выбрать заново. Минимум запросов и правок, простая логика, не остается тупика, но чуть напрягаем пользователя.
Тяжелый обсчет интервалов по крону? Кладем результат в кеш и отдаем фронту из кеша. Запрашивай хоть каждую секунду. Просто, дешево и быстро. Хорошо дополняет предыдущий вариант, но и само по себе годится.
Неизвестно, когда интервалы обновились, а почему-то все равно надо дергать тяжелый запрос? Делаем еще один эндпоинт, возвращающий дату последнего обновления интервалов. Он дешевый, дергать можно будет часто, а интервалы запрашивать, только если полученная дата свежее, чем на клиенте.
Если на бэке работы не провести, то вот еще как можно выкрутиться на фронте:
Интервалы обновляем однократно перед отправкой формы заказа, а если изменились и выбранные пользователем больше не применимы - выдаем пользователю уведомление и просим еще раз их выставить, показав уже новые. Почти как первый вариант, но без бэка.
В конце концов, можно отслеживать активность пользователя на вкладке с сайтом: движения мыши, клики, нажатия клавиш. Если он надолго ушел, то перестать впустую нагружать сервер, а загрузить интервалы, когда он вернется после перерыва.
Большое спасибо за комментарий, действительно, работы на беке провести невозможно. Первый вариант был реализован до того, как я приступил к работе, вопрос в том, что бизнес хотел, что бы интервалы обновлялись автоматически.
Идея с отслеживанием движения мышки действительно хороша, попробую реализовать.
который срабатывал через несколько секунд, когда наступала новая минута, и далее через setInterval каждую минуту
Интересно, не получится-ли так, что все зашедшие на страницу клиенты будут отправлять запрос на еле живой бекенд практически одновременно (по границе минут) и не добьёт-ли его такой характер нагрузки?
Хотя в коде у вас это сделано не так как в описании, что оставляет некоторые шансы.
onTimeout = setTimeout(() => {...}, currentTiming);
onInterval = setInterval(timer, currentTiming);
currentTiming это сколько секунд осталось до конца минуты. Использование такого значения в качестве задержки в первом случае похоже на правду. Но подставляя его в интервал, вы получаете запуск функции с некоторой плавающей периодичностью не раз в минуту, а где-то чаще, где-то - реже.
Первый раз у нас высчитывается время, до обновления минуты. Каждый последующий запрос будет проходить с интервалом в минуту. Так как данный функционал лежит на проде уже две недели. Думаю, что это показывает состоятельность решения. Всегда можно сделать лучше, однако, как показало время, данное решение имеет место быть.
Как побороть интервалы или разберитесь с бэком