Посоветуйте замену Faye

Я бы взял ws и всё остальное сделал бы сам.

Мимокрокодил.

я кроме центрифуги ничего не нашел. она работает с любым «стеком», т.к. всё взаимодействие с твоим приложением по http (хуки там называются connect proxy, rpc proxy). в этом классе продуктов не так много мне показалось. внедряю ее в проект. в бесплатной версии некоторые ограничения функциональности, но что поделаешь.

Нужна поддержка каналов (неймспейсов), желательно с wildcards

каналы там разных типов, семантика настраивается через имя канала. я пользуюсь в итоге только per-user private channels. (#username). есть там еще namespaces, но это что-то другое.

Желательно иметь какой-то механизм, чтобы при переподключении события не терялись.

там это есть, но я не пользовался.

Нужны пинги, чтобы корпоративные прокси не рубили коннекты

есть но частота не регулируется, насколько я знаю.

На клиенте достаточно только поддержки вебсокетов

без фирмаенной либы, там работает WS (и SSE) в одностороннем режиме (клиент слушает сообщения с сервера).

если надо двусторонний WS, то надо или реализовать его протокол (в простом случае он простой), либо использовать его клиентскую библиотеку. я пробовал односторонние и двусторонний с библиотекой.

у него автор в дискорде помогает, советует. но там может быть пару дней подождать надо. телега еще есть.

у проекта видно не очень хватает ресурсов на документацию, но то что было мне надо - всё нашел.

да, добавлю. в проде пока не использовал. вообще автор вроде где-то утверждал, что не на ней, но на родственном коде у него очень большие чаты работали. оттуда видимо идет распределенная архитектура, redis и пр. но я redis-режом пользоваться не планирую.

в установке оно представляет собой копирование одного elf файла и опционально создание конфига. но у них там кажется и пакеты и докеры были.

Нужно с сервера пушить события в веб-страницу

GraphQL?

Желательно иметь какой-то механизм, чтобы при переподключении события не терялись

Кмк, без участия клиента (запрос при переподключении) не обойтись.

Сервер без разницы на чем

https://graphql.org/code/

при переподключении события не терялись

имей в виду, там это надо будет отдельно включить в конфиге. там кажется одна настройка + ёмкость накопителя где-то нужно выставить. по-дефолту выкл. но я этой фичей не пользовался.

Я вобщем-то в доку по центрифуге заглядывал, примерно в курсе как оно. Интересуют моменты, которые в доке не встретишь. Если читать доку по socket.io и faye, то там тоже все зашибись. А по факту, первое это совсем кривое говно, а второе протухло настолько, что даже PR стать бесполезно.

в этом классе продуктов не так много мне показалось.

Угу. А реально работающих еще меньше. Что еще смотрел из открытого?

в бесплатной версии некоторые ограничения функциональности, но что поделаешь.

А чего там такого критичного? Агрегация статистики «кто онлайн» обычно нафик не нужна, и на мелких объемах делается на коленке.

каналы там разных типов, семантика настраивается через имя канала. я пользуюсь в итоге только per-user private channels. (#username). есть там еще namespaces, но это что-то другое.

Меня смущает, что они педалируют юзать лимитированное количество per-user каналов, вместо подписки на кучу публичных. Вот я например открыл 10 вкладок с разными темами, и хочу чтобы мне там прилетали апдейты о новых постах.

Вроде очевидно, что это паттерн с кучей каналов (на каждую тему свой). А если приватные каналы и мапинг сбоку хранить - нафига тогда центрифуга, если только половину типовых задач решает. Или в центрифуге какие-то более внятные альтернативы есть?

если надо двусторонний WS, то надо или реализовать его протокол (в простом случае он простой), либо использовать его клиентскую библиотеку. я пробовал односторонние и двусторонний с библиотекой.

Мне надо 2 относительно простых вещи:

1. Входящие нотификации
2. Исходящие с подтверждением доставки. Сохранение последней позиции скроллера на сервере (куда страницу умотали). Долбать каждую секунду аяксом не хочется, тем более он к паре байт реальных данных прифигачит километр кук.

Ну плюс еще механизм отписок, когда юзер открыл 50 вкладок, потом закрыл половину, и ему апдейты страниц стали не нужны.

как мне кажется, единственный способ понять подойдет она или нет - это попробовать начать на ней делать.

там самое сложное - это под свою задачу подобрать способ как это сделать на базе того в ней доступно.

Меня смущает, что они педалируют юзать лимитированное количество per-user каналов, вместо подписки на кучу публичных. Вот я например открыл 10 вкладок с разными темами, и хочу чтобы мне там прилетали апдейты о новых постах.

затрудняюсь сказать как это правильно сделать на ней. если это прям какая-то _подписка_ которая хранится в БД, то при создании поста по БД определяешь список заинтересованных (#user123456,...) и делаешь отправку на этот список (циклом или через broadcast в API).

если по обыкновенному каналу на каждую тему - оно работать-то наверное будет, вопрос насколько эффективно. насколько помню, каналы «исчезают» из оперативки как только пропал последний подписчик.

насколько я помню, в рантайме ты можешь пользователей подписывать/отписывать, я просто этим не пользовался, там много способов как подписать.

Что еще смотрел из открытого?

ничего. про socket.io на hacker news в комментах кто-то сказал, что не понимает как оно может быть так популярно будучи настолько глючным. на SO тоже говорил кто-то боролись с ней (что-то с памятью кажется).

Исходящие с подтверждением доставки

я пользуюсь т.н. RPC-proxy. если с библиотекой centrifuge.js, то центрифуга дождется ответа от твоего приложения, и этот ответ станет ответом RPC вызова. - вот как бы и подтверждение. т.к. механизм превращается в запрос-ответ, а коннект полнодуплексный, библиотека нумерует каждый «call» и ответные сообщения (они скорее всего в любом порядке) соотнесет с вызовами. без библиотеки это тоже просто делается соотнесением «id». ты не забывай только что на backend у тебя всё равно образуются запросы, да без SSL, да по loopback, но их всё равно обслужить надо.

А чего там такого критичного?

«кто онлайн» вроде бы в платной как-то решено. но я сделал отдельный костыль рядом по рекомендации автора. более того, можно поллить серверый API, просто автор говорит, что это не очень затея.

плюс кажется возможность прикрепить произвольную информацию к пользователю была в платной. но я сделал путем вшивания в username.

в веб-админке отладочных фич меньше в платной.

как мне кажется, единственный способ понять подойдет она или нет - это попробовать начать на ней делать.

Не, там вопросы насчет общей стабильности. Когда вдруг клиенты начинают глючить. Это через «попробовать» не проверяется. Только собрать статистику с больших продакшенов. Ну и я еще трекеры смотрю, чтобы не висело годами фатальных косяков.

Вообще, во всех этих раздавалках сообщений, самая хрупкая часть - это связь клиент-сервер. Когда к одному юзеру с подвывертом приходит писец и хрен чего воспроизведешь. На https хотя бы всратые прокси не могут гадить, а на http раньше можно было только вдоль делать. Но там все равно остается вопрос с пингами, их должен сервер пулять, т.к. клиенту браузер может кислород перекрыть если вкладка в фон уйдет.

про socket.io на hacker news в комментах кто-то сказал, что не понимает как оно может быть так популярно будучи настолько глючным.

Я по результатам тоже в осадок выпал. Такое впечатление, что это юзала только толпа фанбоев на сайтах с парой человек онлайн.

Faye можно выправить, но я задолбался чинить чужое вместо разработки своего проекта. Там похоже автор просто болт забил, т.к. за много лет не приземлил кучу патчей, из-за которых народ форкался. А жаль. Архитектура там «правильная», видно что не школьник делал.

В общем, написал автору центрифуги напрямую. Может все проще решится.

их должен сервер пулять, т.к. клиенту браузер может кислород перекрыть если вкладка в фон уйдет

Какого-то значимого тестирования эта схема не имела, но например у меня клиенты запрограммированы отправлять на сервер пинг раз в 30 секунд, причем не по ws, а обычным https. Фоново отдельный скрипт выбирает из таблицы клиентов не приславших пинг - они считаются зависшими. Этот же скрипт просит (через backend api) центрифугу разорвать все ws/sse подключения с данным userid. Разрываемые в этом случае ws-подключения скорее всего тоже проблемные.

Сервер->клиент пинги шлет сама центрифуга (пустое ws/sse сообщение). Насколько я понимаю, отвалившиеся клиенты выявляются, если вызов write() выдаст ошибку.

В общем, написал автору центрифуги напрямую. Может все проще решится.

Если будешь пробовать на ней сделать, то будет интересно, если черкнешь пару строчек по результатам.

Какого-то значимого тестирования эта схема не имела, но например у меня клиенты запрограммированы отправлять на сервер пинг раз в 30 секунд, причем не по ws, а обычным https.

Не переживай, успеешь еще хлебнуть говна, когда в продакшен выкатишь :). Тебя ждет много очешуительных открытий.

https://github.com/nodeca/tabex/issues/5 вот тут делал пометки, чтобы очередной раз коленом в салат не вступить. Можно таймер в вебворкер обернуть https://github.com/nodeca/tabex/blob/master/lib/timer.js. Это работает чуть получше, но всё равно не до конца прошибает.

Только пинги с сервера спасут отца русской демократии. И то не факт.

Если будешь пробовать на ней сделать, то будет интересно, если черкнешь пару строчек по результатам.

Мне деваться некуда особо. С автором списался, договорились что соберусь мыслями, и разом всё порешаем. Ну чтобы не тратить его время на тупняк, если в доке уже написано.

https://gist.github.com/puzrin/8811150034014636f4ff5430c5757ed7 - пока начал писать гист.

Ты кстати подумай, может тебе нужен грамотный шаринг клиента между вкладками? Я по любому буду tabex рефакторить. Но если ты хорошо знаком с проблемой, и можешь сбацать ТЗ, или чеклист проблем, то готов учесть. Бесплатно без смс.

Я о том, что надо по дефолту стараться засунуть клиента в SharedWorker, а если не получится - химичить с BroadcastChannel и Visibility API. Если совсем край - то через IndexedDB / LocalStorage. Ну и менеджмент подписок надо прилепить, потому что у каждой вкладки они свои.

если ты хорошо знаком с проблемой

Вообще не знаком. С темой WS до этого не сталкивался, то есть делал из общих соображений каких-то. Хотя догадываюсь, что заморочек тут полно. Делаю бекенд, когда фронтенд-человек подключится, эти вопросы будем уже по факту решать.

потому что у каждой вкладки они свои

Для свой задачи я пошел по пути максимального упрощения: у каждой вкладки своё соединение, но все эти соединения одинаковые и имеют одну подписку (#userid). Клиент игнорирует нерелевантное для данной вкладки, если такое возникнет. Возможно, это не идеальное решение. То есть шлю на все соединения данного user id, и да, в итоге все его вкладки/браузеры/компьютеры это получат.

А что глючит в socket.io? Юзаю в одной поделке.

Пока на сайт заходит два васи и три пети - ничего. Будет несколько тысяч юзеров с рандомных сетапов - узнаешь.

Ну а просто сказать в чем была конкретно у вас проблема без оттягивания неизбежного трудно что ли?

Нестабильная работа, жалобы юзеров. Мне про оттенки говна помнить много лет не интересно. Достаточно помнить, что не надо связываться.

Только пинги с сервера спасут отца русской демократии. И то не факт.

В socket.io с третьей (?) версии стали слать пинги с сервера. IMHO лучше не стало.

У меня в проде работает (довольно паршиво) чужое поделие на socket.io.
В этом случае проблема уровнем выше, возможно порождённая тем, что изобретатели запутались и переломали себе в этом socket.io все конечности.
Ну и разобраться теперь в этом месиве проблематично.

ХЗ. Я давно на фонтелле приворачивал socket.io, и радостно завернул в него RRC. Гордился достижением недели 2, и все это время меня дрюкали в трекере. Мол, круто конечно, но очень больно. В итоге после долгих попыток побороть сдался и снес нахрен.

У таких поделок самая подлянка в том, что жопа настает только на реальном продакшене, и резко огребаешь в фидбек толпу народа. Это даже на опенсорсах, где никто никому не должен, весьма досадно.

Не о чем конечно, но ок, не помните так не помните.

жопа настает только на реальном продакшене

А как думаешь, с какого объёма вообще стоит озабачиваться?

У меня сейчас в пике 80 веб-сокетов от сотрудников раскиданы на четыре сервака.
Потребность что-то мультикастить или бродкастить отсутствует – каждый получает только своё.
В каждый коннект мультиплексируется до полусотни «потоков». Вот мне кажется, что если забить на мультиплексирование и нагло открывать по сокету на каждый поток, то для сервера разница между 20 сокетами и тыщей будет незаметна.
Ну и на клиенте, что один сокет и необходимость разбирать чего пришло, что полсотни без разбора – один чёрт.

На серваке до 1000 коннектов я бы особо не парился даже если на яваскрипте написано. Не те объемы. Если конечно по 1000 сообщений/сек каждому юзеру пулять не надо.

Другое дело - качество архитектуры и кода.

А как думаешь, с какого объёма вообще стоит озабачиваться?

Когда попрут пачки клиентов, сетап которых ты не можешь контролировать и предсказывать (у каждого свои операционки, браузеры, провайдеры).

На 1000 рандомных юзеров ты гарантированно узнаешь, как удивителен и разнообразен мир. На 100 - ну как повезет. От пары человек можно и отбрехаться, сказать что антивирус мешает и вообще сами дураки :)

Если будешь пробовать на ней сделать, то будет интересно, если черкнешь пару строчек по результатам.

Пока дошли до того, что

• логику пингов возможно стоит переделать
• в js апи должны быть какие-то внятные жизненные циклы, а не просто бешеная хреновина изрыгающая события.

Я вписался варианты апи рисовать, и через 2-3 сбивки посмотрим, чего получится. Общее направление - надо пытаться прикидываться обычным tcp-соединением, не вываливая на юзера внутреннюю машинерию. То есть, если соединение можно восстановить за указанные таймаунты, и истории канала хватает, то юзеру вообще не надо знать что случилось. А если чего-то не хватает, то надо говорить «стрим сдох, делай новый», и ни каких «ой мне плохо, помираю, подержите за руку»

Если у тебя накопились пожелание или идеи - могу учесть.

Осмысленного ничего не скажу. Рад, что ты туда повязался. Спасибо таким как ты людям.

Через месяц-другой будет новое клиентское апи. Сначала - только для вебсокетов (браузеры без вебсокетов практически полностью протухли). Потом добавится фолбечный транспорт типа eventsource+rpc, без тонны извращений которые тянет SockJS (который еще и протух прилично).

Вроде порешали ключевые моменты, как все сделать «правильно», не разломав потроха центрифуги и месседжингивый протокол.

SockJS было актуально во времена, когда Comet делали трюками типа long polling и пр. сейчас особо толку-то он него.

кстати люди вновь открыли для себя SSE https://news.ycombinator.com/item?id=30312897

Ну вот мы разгребали, какие куда данные надо гонять, и выясняли, в какой момент все пошло «не туда». Там из-за SSE появились серверные подписки, а из-за SockJS всякие sticky sessions на балансере.

А надо было слепить свой фолбек для вебсокетов из [SSE+RPC] + проксировать rpc запросы на нужную ноду, и получить более простое и прозрачное решение.

Ну и более внятную абстракцию для юзера, типа виртуального стрима, который дохнет при проблемах. Вместо безумной пулялки евентами, которые фик знает как обработать чтобы ничего не пропустить.

В общем, пока сделаем отдельный пакет только для вебсокетов, а потом допишем туда остальное и будем думать как депрекейтить старое (но уже без меня).