События сервера для мобильных web-приложений
Некоторое время назад возникла потребность реализовать в своём мобильном web-приложении оповещение клиента (фронт) о событиях, происходящих на сервере (бэк). Я рассматривал технологию Server Sent Events, как более простую альтернативу Websockets ("HTTP & text" vs. "TCP & binary").
> Без помощи со стороны web-приложения у сервера нет возможности определить, это один браузер с одного мобильного устройства открыл два отдельных SSE-соединения или это два разных браузера с разных мобильных устройств открывают соединения из-за одной точки доступа.
Что-то мне здесь стало страшно за безопасность. Механизм COOKIE давно придуман (это то, что вы называете далее "некий UUID"), ну а здесь это всё же Application ID. и идеально ему не доверять, и каждое мобильное приложение перед началом работы получает свой ID от сервера (ID очень "сложный", по сути в нем и логин и пароль)
Синхронизация между двумя (хорошо, если их две) удаленными точками может реализоваться достаточно просто списком событий (просто данные); тем самым можем допустить работу приложения какое-то время в офлайне (например, закидывать продукты в корзину; а сервер потом в пакете обновления "скажет", что этого нет, здесь уже другая цена - приложение, соответственно реагирует). Идентификатор обязательно последовательный - так контролируем пропуски. У каждого есть очередь на отправку и статус подтверждения получения. Если важно время - становится сложнее, но иногда достаточно окончания "транзакции" - т.е. есть сообщение до которого все предыдущие события должны быть корректно обработаны и о них можно забыть.
Вы правы, можно использовать механизм cookies. Но нужно предварительно "посадить" куку на клиента. К тому же в качестве EventSource'а может выступать не тот сервер, с которого закачивались исходники фронта (и ставилась кука):
```
const source = new EventSource('http://domain.com/path/to/sse/:id');
```
в этом случае альтернатив GET-переменной я не вижу.
каждое мобильное приложение перед началом работы получает свой ID от сервера (ID очень "сложный", по сути в нем и логин и пароль)
Ничего не имею против того, чтобы использовать его в качестве ID для канала. Вопрос не в том, что использовать в качестве ID, а в том, нужен ли такой ID или нет. IMHO, нужен.
тем самым можем допустить работу приложения какое-то время в офлайне ... а сервер потом в пакете обновления "скажет" ...
Тут другое направление, от бэка к фронту. Это бэк какое-то время работает в "оффлайн", отправляя данные на фронт, которые фронт не получает, т.к. отвалился. И у сервера нет возможности самостоятельно узнать, это надолго или навсегда.