Вопрос не про технологию, вопрос про алгоритм ее использования.
Есть игра реализованная как Single Page Application. В игре есть много разделов: дом, магазин, чат, турнир и т.д.
Пользователь заходит в чат, чтобы не пропустить чужие сообщения - раз в секунду делается обращение к серверу.
Пользователь заходит в турнир, чтобы не пропустить появление соперника - раз в секунду делается обращение к серверу.
И так почти по всем разделам.
Для того, чтобы не дергать сервер каждую секунду давно придумали Long Polling, WebSockets и Server-Sent Events. Мои задачи полностью покрывает SSE, но я не понимаю, как правильно использовать эту технологию.
Вариант 1. При заходе в игру пользователь подключается к своему единственному персональному каналу.
А что дальше?... Я на стороне бека знаю, что вот такой пользователь сейчас держит канал, а что мне туда публиковать? Я же не знаю, пользователь сейчас в чате или в турнире, или в настройках. А если в чате, то в какой комнате?
Получается, когда кто-то пишет сообщение в конкретную комнату чата, я должен найти всех пользователей, которым доступна эта комната и у кого есть активное подключение, и отправить всем информацию о новом сообщении? А если пользователь сейчас сидит в турнире и эта информация ему абсолютно не интересна? Да и выборка всех кому доступна комната и кто подключен может оказаться дорогой, если проект большой.
Вариант 2. При заходе в раздел пользователь подключается к каналу раздела.
Зашел пользователь в турнир - подключились к каналу турнира, вышел - отключились.
Зашел в чат - подключились к каналу комнаты, вышел - отключились.
Звучит вроде красиво, а на деле, не окажется ли, дорого? Ведь каждый заход в раздел будет сопровождаться дополнительным соединением для подключения к каналу.
Вариант 3. При заходе в игру пользователь подключается ко всем доступным ему каналам.
Мы знаем, что у пользователя в чате 15 комнат, турнир, арена, уведомления, итого подключаем его к 18 каналам.
Но, тут опять же, он сидит в одном разделе, к чему ему информация из другого?
Позволит ли сервер и браузер держать большое количество каналов?
Ну,
1. SSE полностью не покрывает ваши задачи. Вы обращаетесь в оба направления
2. Вам необходимо иметь систему событий на бэке и организовывать subscribe/unsubscribe на определенные типы сообщений по параметрам
3. в любом случае придется хранить список подписчиков и каждому отправлять отдельно, если только у вас не websocket.
И, как ни удивительно, но для всего вышеперечисленного, если, конечно, научиться читать документацию и не иметь сверхвысоких нагрузок - подходит GraphQL ибо у него есть и подписки, и команды (мутации) и просто получение нужных данных (query).
1. Обращение в направлении сервера делается классическими GET/POST запросам. SSE мне нужно, чтобы не дергать сервер каждую секунду с вопросом "а есть ли новые данные".
п2, п3. Это все понятно, я написал в вопросе, что речь не о технической части реализации технологии, а об алгоритме ее использования.
