на выбор у вас есть 3 варианта:
1. callback как в ответе от Дмитрий Беляев
2. вернуть промис
3. использовать async/await (который в результате веренет промис)
В любом случае, если вы хотите оставить вызов вашей api неблокирующей, то других вариантов у вас нет
Для таких вещей лучше использовать WebRTC.
Да сложно в первый раз, но в результате вы получаете кучу плюсов:
- снижение общей нагрузки на ваш сервер
- существенное снижение трафика обслуживаемого вашим сервером
- улучшение скорости связи между клиентами а как результат улучшение качества связи
Надим Закиров, ох извините, действительно не то скинул. Имел ввиду Object.Observe, но пишут что он давно уже deprecated и рекомендуют использовать proxy (правда Object.Observe, опять выдвинули как кандидат на реализацию)
hey_umbrella, питон не знаю, потому чисто алгоритмически распишу.
организация очереди:
1. создается своя библиотека/модуль/пакет содержащий:
- в самом простом случае пустой массив
- экспортируемую функцию отправки сообщения, например sendMessage, принимающую в качестве параметров ID группы/канала/пользователя которому необходимо отправить сообщение и само сообщение. Данная функция просто добавляет в массив объект содержащий эти 2 параметра
- внутри библиотеки средствами python (Timer) организуется бесконечный асинхронный цикл, срабатывающий раз в секунду который делает следующее
- проверяет массив на наличие в нем записей
- если записи есть то вынимает (достает удаляя из массива) 30 записей и в цикле обрабатывает каждую, отправляя сообщение адресату
2. везде в коде, где отправляются сообщения пользователям вы:
- подключаете созданную вами библиотеку
- заменяете функции отправки сообщений на вызов функции экспортируемой из этой библиотеки
Это очень примитивный пример, но для понимания механизмов самое то. А как справитесь - замените массив на БД, добавте в таймер проверку на то были ли фактически отправлены предыдущие 30 сообщений и получил ли их сервер и многое другое. Там вы уже сами начнете видеть ситуацию и возможные пути решения возникающих проблем.
Вот честно, 4 раза перечитал ваш вопрос и нифига не понял что вы хотите получить в результате)))
Не соизволите ли нарисовать картинку, на которой схематично изобразите вашу ситуацию и то что вы хотите получить в результате?
PS: Наверняка вам не раз родители говорили учить математику и геометрию? А раздел про тригонометрию в 8,9 и 10 классах вы наверно вообще проспали?
hey_umbrella, и какие вы из увиденного сделали выводы? Голова у вас для чего предназначена, думать или ложкой в нее тыкать?
У меня большое количество юзеров ,и бот не выдерживает их,что делать?
Уменьшать количество сообщений рассылаемых ботом. Вот прямо клянусь, никому из получателей нафиг ваши рассылки не нужны. Именно так превратили интернет в помойку бесконечными никому не нужными спам рассылками, сраными лендингами, попытками впихнуть нахрен никому не нужное дерьмо. Хуже спамеров и интернетпродаваторов только комивояджеры, приходящие к тебе домой и впаривающие престарелым людям гавеный пылесос по цене в 200 000.
По существу вопроса:
Решение 1. Создать ТГ канал, в который кидать общую инфу для заинтересованных лиц. Сам факт нахождения человека в канале является его согласием получать от вас вашу рассылку.
Решение 2. Сделайте в боте возможность подписаться на рассылку. При этом, саму рассылку разбейте по категориям и добавьте пользователям возможность выбора нужных категорий. Создайте программную очередь отправки сообщений. Для этого все сообщения рассылки не кидаются напрямую пользователям а закидываются в некий массив/бд/файл из которого бот не чаще чем раз в секунду берет 30 записей и отправляет их адресатам.
Сергей Сергей, вот прямо поддерживаю. Незачем конкурентов плодить. Пусть остаются неучами. Тогда у нас и ЗП выше будет и конкуренции меньше (это не сарказм))))
Сергей delphinpro, я с этим даже не спорю, но вы похоже неверно поняли мой коммент. Я имел ввиду что чем решение на серверном PHP предложенное вами будет отличаться по цене от аналогичных решений на других серверных ЯП? Стоимостью хостинга? Сколько не гуглил - цены на них примерно одинаковы, а если рассматривать vps или vds то разницы вообще нет.
Shandy, да все верно, просто как мне кажется, вам сказали не то, что дешевле будет конкретно на php, а то что дешевле будет отправлять сообщения в ТГ и на почту с сервера а не с клиента. А вот на каком языке у вас будет крутиться бэк - это выбираете вы, хотите php, хотите python или perl или nodejs или golang или еще что-то. Все эти варианты подойдут.
PS: возможно что я ошибаюсь и DevMan имел ввиду конкретно именно PHP. Но если это так, думаю он поправит меня в комментах или конкретизирует ответ))) Тут правда я не пойму почему PHP будет дешевле. Сколько не кручу ситуацию в голове, не вижу особой разницы в цене для любого серверного решения.
DevMan, ну не знаю, так себе заполненный профиль на хабркарьере и за пол года предложений больше сотни. А после прохождения 10 собеседок 7 готовы начать работать со мной (остальным не понравились мои пожелания за гибкий график), так что у меня был выбор к кому идти. И это при том, что профильно я никогда в данной сфере не работал (25 лет был кадровым военным)
FanatPHP, ну что вы за человек? Очень хочется надеяться что вы все прекрасно поняли. Для корзины на сервере по любому нужна как минимум привязка пользователя к корзине (идентификация пользователя, пусть даже по случайно генерируемому sessionID, хранящемуся в куках клиента или в локалсторадже). Но вот если ограничиться только идентификацией (без авторизации) то пользователь теряет корзину при переходе на другое устройство и/или браузер. Так зачем в таком случае нужно хранить корзину на сервере если в отсутствии авторизации того же эффекта можно добиться храня ее на клиенте в localstorage???
Сервер ведь не резиновый, и современный веб имеет тенденцию перекладывать на клиент все, что можно на него перенести если это не влечет проблем с безопасностью и с поисковой оптимизацией.
Я кстати не очень понял твои идеи про авторизацию.
Видимо вы многое не понимаете.
Ну то есть ты никогда корзину не делал
Что и требовалось доказать :)
Вы так и не привели ни одного аргумента. По всей видимости у вас их нет, что и требовалось доказать.
FanatPHP, уважаемый, давайте не будем пустомелить. Просто назовите хотя-бы одну причину при отсутствии авторизации пользователя на сайте (ну так, чисто в образовательных целях)).
на выбор у вас есть 3 варианта:
1. callback как в ответе от Дмитрий Беляев
2. вернуть промис
3. использовать async/await (который в результате веренет промис)
В любом случае, если вы хотите оставить вызов вашей api неблокирующей, то других вариантов у вас нет