Node.js + Socket.io: шаблонный сервер или браузер?Загружать контент через ajax или socket.io?

Question

Я уже задавал подобный вопрос, но этот вопрос немного отличается / специфичен:

Я собираюсь начать разработку сайта социального сообщества (для локальной группы пользователей) с такими функциями, как временная шкала, IM/ чат, форумы, ...

Node.js и socket.io (или now.js) на сервере.jQuery (и, возможно, backbone.js или аналогичный) на переднем конце.Контент загружается через socket.io или ajax, а навигация - по хешу URL.

Есть две вещи, в которых я просто не могу решить, в какую сторону идти.Я надеюсь, что есть некоторые люди, которые могут дать хороший или плохой опыт.

1. Шаблонирование на сервере или в браузере?Я не уверен, что лучше загрузить полный сайт html + живые обновления (также в формате html) для временной шкалы, сообщений на форуме, чата / чата, ... или использовать что-то вроде REST api через ajax или socket.io и делатьшаблонизация на сайте клиента.Я никогда не делал этого раньше.Вам нужно скачать шаблоны и т. Д. И т. Д. Кто-нибудь сталкивался с этим?Есть также 2 способа реализации API, подобного отдыху: например, запросить сообщение на форуме, затем запросить пользователя, связанного с этим сообщением и т. Д. (Точно так же, как на стороне сервера MVC) - или - запросить сообщение на форуме, и сервер ответит всеминеобходимая информация.

2. Загрузка содержимого через ajax или socket.io?Я определенно использую socket.io или now.js для общения в реальном времени (IM, чат) и pubsub (на главной странице -> подписаться на новые обновления графика времени, в теме форума -> подписаться на новые сообщения).Но должен ли я также загружать HTML (или предоставлять REST-подобный API, см. Вопрос 1) через сокет?Когда люди открывают сообщения на форуме во вкладках (что я обычно делаю часто), это будет означать много сокет-соединений.И я не уверен, сколько времени потребуется веб-сокету для установления соединения.

Итак, есть 4 способа сделать это:

1. HTML через AJAX- вероятно, самый стабильный способ, который не требует большого количества javascript для создания шаблонов - Браузер может использовать открытые HTTP-соединения для запроса содержимого.
2. HTML через socket.io - Веб-сокет должен быть установлен для загрузки контента (может быть медленнее)
3. API через AJAX - так как ему, вероятно, нужно больше запросов в виде HTML через AJAX, могут быть некоторые заголовки HTTP-заголовка + вам нужно проверять подлинность в каждом запросе - я не являюсь другом слишком многих ajaxзапросы.
4. API через socket.io - Socket должен проходить аутентификацию только один раз, и вы можете запрашивать объекты API на лету.Тем не менее, я бы по-прежнему загружал шаблоны и JS через HTTP для кэширования в браузере.

Я знаю, что это огромный пост, но я спорю уже много дней и просто не могу решить, как это будетМного работы по переключению системы когда-то начали развиваться.Это не публичный проект, он ограничен ~ 10k-15k местными жителями и поэтому не должен быть , что идеальным, по моему мнению, хорошая возможность узнать что-то новое (я совершенно новичок в ноде, классикаPHP MVC + jquery dev здесь).

Answer 1

Я думаю, что вы должны использовать API RESTful на бэкэнде, позволить шаблонированию появляться только на внешнем интерфейсе (возможно, с Backbone) и использовать Socket.IO только для реальных вещей в реальном времени (таких как чат). Не имеет смысла использовать веб-сокеты для чего-то вроде загрузки HTML, потому что это, скорее всего, никогда не изменится.

Итак, мой голос:

1) HTML через AJAX
2) API через AJAX
3) Связь в реальном времени, например обмен сообщениями в чате (или другие вещи, которые постоянно меняются) через Socket.IO

Answer 2

Хотя на самом деле нет однозначного ответа, так как это зависит.

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

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

Если продвинуться на несколько шагов дальше, если вы посмотрите, начиная с проекта примеров потоков Yahoo на github, вы можете использовать ту же логику как на стороне клиента, так и на стороне сервера, включая рендеринг с представлениями React. Это не простое решение, и потребует некоторой работы.

Для интерактивных элементов рендеринг на стороне сервера может быть минимальным, если ваши магазины запускают передачу событий через sockjs / socket.io, когда клиент запускает биты chat / im.

У вас будут проблемы с масштабируемостью, когда речь идет о работе с несколькими процессами, и вам, вероятно, понадобится цепочка пабов / подчиненных, поддерживаемая БД, для более длительных циклов повторного подключения или пропущенных сообщений IM. Там нет волшебной пули.

Прямо сейчас мне нравится flux + реагировать ... Когда выйдет Angular2, он может иметь лучшую историю для рендеринга на стороне сервера.