Это вопрос, касающийся одностраничных веб-приложений, и мой вопрос выделен жирным шрифтом.
ПРЕДУПРЕЖДЕНИЕ:
Я не эксперт в этом вопросе, и, пожалуйста, поправьте меня, если я ошибаюсь в части моего понимания того, как я думаю, HTTP и WebSockets работают.
Мое понимание того, как работают API-интерфейсы HTTP restful, заключается в том, что они не сохраняют состояния. Мы используем такие инструменты, как connect.session (), чтобы внедрить некоторый тип состояния в наши приложения на более высоком уровне. Поскольку каждый отдельный запрос является новым, нам нужен способ повторной идентификации себя на сервере, поэтому мы создаем уникальный токен, который отправляется туда и обратно.
Промежуточное программное обеспечение сеанса Connect решает эту проблему для нас довольно круто. Поместите его в свой стек промежуточного программного обеспечения, и к каждому запросу для всего приложения будут добавлены сеансы потрясающего соуса. Посыпать рукопожатие, и вы можете передать информацию о сеансе в socket.io довольно легко, даже более круто. Используйте RedisStore для хранения информации, чтобы отделить ее от вашего приложения Connect / Express, и это еще более круто. Мы говорим здесь о двойной радуге.
Так что сейчас у вас теоретически может быть одностраничное приложение, которое не зависит от connect / session, потому что вам не нужно более 1 сеанса (начального рукопожатия), когда речь идет о работе с веб-сокетами. socket.io уже дает вам легкий доступ к этому sessionId, проблема решена.
Вместо этого рабочего процесса аутентификации:
- Получить адрес электронной почты и пароль из почтового запроса.
- Запросите выбранную вами БД по электронной почте, чтобы получить хэш пароля.
- Сравните хэши.
- Перенаправить на "ОК!" или "NOPE!".
- Если все в порядке, сохраните информацию о сеансе, и пусть connect.session () по большей части обрабатывает остальное.
Теперь оно становится:
- Прослушивание события входа в систему.
- Получить адрес электронной почты и пароль от обратного вызова события.
- Запросите выбранную БД по электронной почте и получите хэш пароля.
- Сравните хэши.
- Издайте "ОК!" или "НОПЕ!" событие.
- Если все в порядке, делать какие-то вещи, о которых я сейчас не буду думать, но такой же эффект должен быть возможен?
Что еще мы выиграем от использования Connect? Вот список того, что я обычно использую:
- регистратор для режима разработки
- Favicon
- статический сервер
- Паспорт (библиотека аутентификации, которая зависит от Connect / Express, аналогично тому, что предлагает Everyauth)
Код, который загружает исходное одностраничное приложение, будет обрабатывать настройку статического сервера и favicon. Что-то вроде паспорта может быть более сложным для реализации, но, конечно, не невозможно. Все остальное, что я перечислил, не имеет значения, вы можете легко реализовать свой собственный журнал отладки для веб-сокетов.
В настоящий момент действительно ли что-то мешает нам иметь один файл index.html на основе http, который инкапсулирует соединение websocket и не зависит от соединения вообще? Сможет ли socket.io действительно работать с этим типом архитектуры приложения, не настраивая собственный HTTP restful API, если вам нужно одностраничное приложение, в то же время предлагая межбраузерную поддержку с помощью его автоматических магических откатов?
Единственный реальный недостаток на данный момент - это кэширование результатов на клиенте, верно? Не могли бы вы включить локальное хранилище для этого? Я думаю, что создание индексируемых / просматриваемых страниц контента для поисковых систем не было бы ЭТОЙ большой проблемой - вы бы в основном создали инструмент, который создает статические html-файлы из вашей постоянной базы данных, верно?