На чем сделать нечто похожее на PUSH-уведомления, но чтобы они приходили не в уведомления ОС, а просто в фронт-енд по ws/http?
Я знаю про такие штуки, как push, webpush и т.д., но насколько я понял, эти уведомления могут приходить только в стандартную систему уведомлений Android/iOS/Windows 10/браузера.
А нужно именно реализовать подобные уведомления, но чтобы приходили просто по WebSocket во фронт-енд от микросервиса на бек-енде, чтобы их там можно было обработать и выдать просто в интерфейсе фронт-енда. А лучше даже и не WebSocket, а HTTP.
Примерно выработал такой алгоритм:
1. Пользователь заходит на страницу. При этом сразу отправляется XHR/fetch-запрос к специальному роуту микросервиса.
2. Обработчик роута зависает, ожидая данные в БД. (Либо чекает БД с небольшим интервалом, либо у БД есть метод, который можно вызвать и он зависнет, пока не произойдет какое-то изменение). А если закончился таймаут HTTP, то клиент опять делает такой запрос. То есть long-polling.
3. И тут на сервере происходит некое событие.
4. Обработчик роута перестает висеть и возвращает данные события клиенту.
5. Клиент получает этот ответ от запроса. Возможно, событий несколько (особенно в случае, если в пункте 2 используется sleep).
6. Клиент заново делает запрос, но на этот раз передает id-ы полученных сообщений в параметрах.
7. Сервер удаляет из таблицы сообщения по этим id-ам, а дальше см. пункт 2.
У каждого клиента есть некий accountName, который лежит в каждом сообщении в таблице, и используется и для добавления сообщений (п. 3), и для получения (п. 4), и для удаления (п. 7). Это защищает от
взаимодействия с чужими сообщениями.
Вроде все хорошо, но как быть, если пользователь откроет несколько клиентов с одним accountName? Какой-то из них обязательно прочитает и очистит очередь быстрее других. А надо, чтобы сразу все получали эти данные.
Можно вместо accountName придумать какой-нибудь id каждому клиенту, но как тогда чистить ненужные очереди, ведь теперь они даже кол-вом аккаунтов в системе не ограничены?
В общем, задача не так уж и проста. Может, есть какое-то готовое решение, чтобы самому этот микросервис не велосипедить?
Как только одна из страниц клиента получит значение, пусть отправляет это в тот же localStorage, а все остальные с него считают и пока пользователь не закроет уведомление пусть оно там и хранится.
ZB Venom, приколы? от моторолы?
А если десктоп и мобилка, а если два разных компа. Да и как опрашивать localStorage, чтобы определить, что туда вдруг что-то прилетело, по таймеру что ли... Вот если не имеешь опыта с темой - зачем пишешь?
По технологиям ajax pooling, server sent events и websocket вам в помощь.
А по логике, если не использовать push сообщения, то придется при установке/авторизации приложения сохранять сгенеренный id устройства в БД. И каждое сообщение будет иметь связку с accountName и устройством. Примерно тоже самое делает firabase или другие сервисы отправки пушей
Средний
Простой
