Comments 25
Модель сообщений крайне плоха в условиях нестабильного соединения:
Сообщения надо везде буферизировать, пока нет возможности доставить.
Сообщения доставляются все по порядку, даже если в конце идёт сообщение, которое делает обработку предыдущих 100 бессмысленным.
Куда лучше работает модель состояний, с которой не нужны Кафки и редиски, ибо хватит и пары простых серверов для обслуживания куда большего числа соединений.
Конечно, в условиях, когда бюджет позволяет приоретизировать и очищать очередь сообщений, это будет лучше. Однако, позволить подобное по финансам может разве что условный яндекс, которому дают деньги. Или банк, который косвенно печатает деньги.
Для малого и среднего бизнеса, который деньги зарабатывает, это неприемлимо, так как на вещь, которая по мнению владельца бизнеса работает сама по себе, будет влито полтора месяца инженерной работы
В условиях нестабильного соединения, я бы предпочёл сразу брать Application Server, такой как Firebase (не для ядерной сверхдержавы), AppWrite или Supabase, где отправка уведомлений на устройства грамотно заложена из коробки.
В идеале, не делать MPA вовсе: есть SPA
Вы не поняли, вам совсем не нужны очереди, это гораздо дешевле.
При разработке Internet of things по WebSocket передаются команды, например, на открытие дверцы турникета. Если python клиент заморозит поток c websocket heartbeat, команда открытия турникета уйдет в молоко, когда запись в бд уже сделана
Ничего не понял. Передавайте не команды, а состояния "турникет открыт" и синхронизируйте его между всеми заинтересованными узлами, а не превращайте турникет в вибратор, присылая пачкой десяток команд на открытие-закрытие.
Как обычно в IoT, владелец завода не понимает разницу между слесарем и кодером до тех пор, пока не упрется в срок договора. Далее приглашают инженера решать вопрос, потом дают ему 2 недели на увольнение и порочный круг Путинизма продолжается
Эта статья именно для тех, кому дали донашивать архитектуру с турникетом-вибратором. При этом даже владелец бизнеса понимает, что код говно, но с темы нужно как-то выскакивать
А зачем делать запись в бд если турникет не открылся?
А зачем такое? Обычно перезагрузка страницы означают что на ней самые свежие данные. А по вебсокетам отправляются только обновления, произошедшие после загрузки
Но если прям сильно надо, то посмотрите на socket.io
В socket.io не кеширует очередь, это лишь адаптер websocket/long polling.
При разработке Internet of things по WebSocket передаются команды, например, на открытие дверцы турникета. Если python клиент заморозит поток c websocket heartbeat, команда открытия турникета уйдет в молоко, когда запись в бд уже сделана
Поздравляю, вы только что изобрели mqtt.
Задачу бы описали, для чего это всё делалось. Но пока выглядит, как овер-инжиниринг. Зачем забивать канал связи? Зачем данные за 1 секунду назад после перезагрузки?
В заголовке написано: MPA
Вот честно. Нифига не понятно ведь. Прочитав комменты понял что не я один такой, а все. И это уже диагноз статье.
Нужна вводная на пальцах. Все мы работаем в разных областях. И даже аббревиатуру можем не знать, что уж говорить про нюансы и свойственную проблематику. Проще надо быть и люди к вам потянутся :)
Что только не придумают, чтобы не использовать старый добрый серверный рендеринг) куда собственно опять всё и возвращается потихоньку.
За Hono респект
Пишем Realtime для Multiple-page application в микросервисной архитектуре