Как эмитить socket ивенты из контроллеров? Как организовать код приложения?
Приложение NodeJS/Express, стандартная структура, главный файл, отдельно роуты, отдельно контроллеры и тд.
Сейчас пробую сокеты. Они подключены напрямую в главный файл. Там же io.on('connection') и тд.
Конечно же это все неудобно и нужно это дело перемещать. Но еще более не понятно вот что:
Допустим, я хочу эмитить сообщение всем клиентом, когда я сохраняю нечто в БД. Т.е. уже в контроллере, где просиходит сохранение в БД и ответ на клиент по рест апи. Как мне там достать socket.emit?
Я нашел только одно решение, когда делают app.io, но мне кажется есть другие варианты.
Как организовывается структура приложения, если надо иметь возможность работать с сокетами по всем файлам?
Вы указали несколько вещей - приложение, REST api, бд и socket. Попробую предположить что у вас есть REST API, которое оперирует данными в БД и вы хотите прикрутить сбоку сокеты. Есть несколько вариантов решения, но есть вопрос - чего вы пытаетесь добиться сокетами?
Иван Шумов, рилтайм оповещения. Например, представим ленту твитов. У меня готово сохранение твитов в БД, но для появления нового твита на странице нужно обновлять ее/делать новый запрос. Я хочу прикрутить в контроллере после успешного сохранения твита в БД, возврат его на клиент (не только создателя, но вообще трансляцию всем кто на этой странице).
В целом, я пока так сделал:
1. создал в главном файле инстанс socket.io
2. создал отдельно файл где общая логика сокетов, вне зависимости от моего рест апи (и сокеты и рест на одном сервере у меня сейчас)
3. имопртирую этот файл с сокетами в главный файл и передаю туда инстанс socket.io
4. ниже в главном файле добавляю к res socket.io, таким образом получая доступ к сокетам во всех контроллерах.
5. вроде все работает!
riddlr, очень любопытно, но жесть как не надежно) ибо если у вас один сокет-сервер то он может упасть по любой причине, не удивляйтесь. Советую между API и Socket.io поставить Message Broker. Для надежности, можно сказать. Еще и удобнее потом будет развивать систему
Иван Шумов, да я понимаю что мое решение вряд ли масштабируется. но сейчас важнее собрать прототип. Message Broker - это значит разбиратся с RabbitMQ с нуля, который я в жизни даже не тыкал.
А что вы посоветуете? Как организовать такую задачу если "правильно"? Получается, в контроллере при создании записи в БД надо отправлять сообщение брокеру, а он уже отельному серверу сокетов? Какие инструменты смотреть, если у меня разработка на Ноде?
riddlr, во-первых брокер ничего сам по себе не отправляет. Он кладет сообщение в очередь из которой обработчики из забирают. Есть push и pull варианты. Разбираться в Rabbit MQ проще простого - у них прекрасный мануал на сайте. Когда он мне понадобился я потратил всего лишь час на то чтобы в принципе начать с ним работать и не больше 10 часов суммарно когда стал ковыряться в плагинах и безопасности.
В принципе идея основная такова что у вас есть апи для постинга сообщений, и есть клиенты. Клиентов много, они могут быть подписаны на разные группы сообщений, а кроме WS клиента у вас потом может понадобиться делать Push Notifications, например, в браузер или приложение. Поэтому архитектуру надо сразу строить с низкой связанностью. Вы можете поставить любое число обработчиков с разной логикой и делать с одним и тем же сообщением сколько угодно логических операций.
REST API просто кладет сообщение в очередь "у меня новое сообщение. Разберитесь кому надо. Данные прилагаю". Понятное дело что все в JSON
И, кстати, меня закидают камнями, но Rabbit MQ куда проще чем Kafka, но они оба решают свои задачи.
Иван Шумов, спасибо за ответ. Обязательно так и буду пробовать все сделать (как только разберусь толком с сокетами). Я правильно понял, при выборе RabbitMQ/Kafka выбирать первый? И кстати, еще вопрос в поддержке этого хозяйства. Человек без продвинутого знания системного администрирования потянет такой зоопарк? На мне и так уже Монга, Редис, и еще Эластик будет. Как у Реббита с этим вопросом? Может стоит посмотреть в сторону облака (вижу у Compose и AWS есть), или они кушать не просят?
Ах да, и посоветуйте пожалуйста клиент Реббита к Ноде! (гугол дает немало вариантов)
И еще - видел Редис тоже для очередей используют. Вы пробовали?
Про Compose не знаю, я с ним не разбирался. Про AWS могу рассказать отдельно много интересного, но там половину наработанных знаний приходится в помойку выкидывать и приобретать новые. Там другие подходы. Но он однозначно того стоит - я сдаю уже вторую сертификацию по нему. Но он не дешев в целом - всегда можно сделать дешевле, но при этом пожертвовать надежностью.
Админить все это не сложно, от слова совсем. Оно же все из коробки ставится и многим компаниям хватает так.
Redis имеет такие возможности, но я пока с нему отношусь скептически. Не слышал еще ни на одном крупном докладе вроде Highload++ или Devoxx чтобы кто-то серьезно говорил про их pub/sub. Все за RMQ, Kafka и AWS SQS/SNS. У AWS есть сервис ElastiCache где можно выбрать Memcached или Redis. Делаем выводы из названия)
Иван Шумов, благодарю за интересный ответ. Меня это все давно интересовало, видимо пришло время этим занятся. Не знаю принято ли тут, поскольку ответ не совсем по вопросу, но если вынесете отдельно, то отмечу решением :)
Простой
